Unit 2 Software Requirements Complt

7/31/2019 Unit 2 Software Requirements Complt

1/28

UNIT -2 SOFTWARE REQUIREMENTS

Software Requirements:

What is Software Requirement?

Ans.: In software engineering, requirements analysis is used for determining the needsor conditions to meet for a new or altered product, taking account of the possiblyconflicting requirements of the various stakeholders or users. Systematicrequirements analysis is also known as requirements engineering. It is sometimesreferred loosely by names such as requirements gathering, requirements capture,or requirements specification. Requirements analysis is critical to the success of adevelopment project.

Requirements must be actionable, measurable, testable, related to identifiedbusiness needs or opportunities, and defined to a level of detail sufficient forsystem design.

Conceptually, requirements analysis includes three types of activity:

Eliciting Requirements : the task of communicating with customers andusers to determine what their requirements are. This is sometimes alsocalled requirements gathering.

Analyzing Requirements : determining whether the statedrequirements are unclear, incomplete, ambiguous, or contradictory, and

then resolving these issues. Recording Requirements : Requirements may be documented invarious forms, such as natural-language documents, use cases, userstories, or process specifications.

What is Software Requirements Specification (SRS)?

Ans.: A Software Requirements Specification (SRS) is a complete description of thebehaviour of the system to be developed. It includes a set of use cases thatdescribe all the interactions that the users will have with the software. Use cases

are also known as functional requirements. In addition to use cases, the SRSalso contains nonfunctional (or supplementary) requirements. Non-functionalrequirements are requirements which impose constraints on the design orimplementation (such as performance engineering requirements, qualitystandards, or design constraints).


2/28

Software requirements is a sub-field ofSoftware engineeringthat deals with the elicitation,

analysis, specification, and validation ofrequirementsforsoftware.

The software requirement specification (SRS) document generates all necessary requirements for

project development. To derive the requirements we need to have clear and thorough

understanding of the products to be developed. This is prepared after detailed communicationswith project team and the customer.

An SRS clearly defines the following:

1. External interfaces of the system: They identify the information which is to flow 'fromand to' the system.

2. Functional and nonfunctional requirements of the systems. They stand for the finding ofrun-time requirements.

3. Design constraints

A Software Requirements Specification (SRS) - arequirements specificationfor asoftwaresystem- is a complete description of the behavior of a system to be developed. It includes a set

ofuse casesthat describe all the interactions the users will have with the software. Use cases are

also known asfunctional requirements. In addition to use cases, the SRS also contains non-functional (or supplementary) requirements.Non-functional requirementsare requirements

which impose constraints on the design or implementation (such asperformance engineeringrequirements,qualitystandards, or design constraints).

Requirements Gathering:

Requirement gathering is usually the first part of any software product. This stage starts

when you are thinking about developing software. In this phase, you meet customers or prospec-tive customers, analyzing market requirements and features that are in demand. You also find out

if there is a real need in the market for the software product you are trying to develop.

In this stage, marketing and sales people or people who have direct contact with the cus-

tomers do most of the work. These people talk to these customers and try to understand whatthey need. A comprehensive understanding of the customers needs and writing down features of

the proposed software product are the keys to success in this phase. This phase is actually a base

for the whole development effort. If the base is not laid correctly, the product will not find aplace in the market. If you develop a very good software product which is not required in the

market, it does not matter how well you build it. You can find many stories about software prod-

ucts that failed in the market because the customers did not require them. An effective

requirements gathering process is perhaps the most critical driver of software project success.Getting the requirements rightand getting the right requirementscan mean the difference

between a successful projectone that satisfies the needs of its users and is delivered on-time

and on-budgetand one that fails.It should come as no surprise that effective requirements gathering involves much more than

asking business users what they want and need. It is a complex process that involves users and

system designers in a collaborative effort that explores both functional requirements and the newpossibilities that technology offers. The great challenge of the requirements process is finding a
http://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Requirementshttp://en.wikipedia.org/wiki/Requirementshttp://en.wikipedia.org/wiki/Requirementshttp://en.wikipedia.org/wiki/Softwarehttp://en.wikipedia.org/wiki/Softwarehttp://en.wikipedia.org/wiki/Softwarehttp://en.wikipedia.org/wiki/Requirements_specificationhttp://en.wikipedia.org/wiki/Requirements_specificationhttp://en.wikipedia.org/wiki/Requirements_specificationhttp://en.wikipedia.org/wiki/Software_systemhttp://en.wikipedia.org/wiki/Software_systemhttp://en.wikipedia.org/wiki/Software_systemhttp://en.wikipedia.org/wiki/Software_systemhttp://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Functional_requirementshttp://en.wikipedia.org/wiki/Functional_requirementshttp://en.wikipedia.org/wiki/Functional_requirementshttp://en.wikipedia.org/wiki/Non-functional_requirementshttp://en.wikipedia.org/wiki/Non-functional_requirementshttp://en.wikipedia.org/wiki/Non-functional_requirementshttp://en.wikipedia.org/wiki/Performance_engineeringhttp://en.wikipedia.org/wiki/Performance_engineeringhttp://en.wikipedia.org/wiki/Performance_engineeringhttp://en.wikipedia.org/wiki/Quality_(business)http://en.wikipedia.org/wiki/Quality_(business)http://en.wikipedia.org/wiki/Quality_(business)http://en.wikipedia.org/wiki/Quality_(business)http://en.wikipedia.org/wiki/Performance_engineeringhttp://en.wikipedia.org/wiki/Non-functional_requirementshttp://en.wikipedia.org/wiki/Functional_requirementshttp://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Software_systemhttp://en.wikipedia.org/wiki/Software_systemhttp://en.wikipedia.org/wiki/Requirements_specificationhttp://en.wikipedia.org/wiki/Softwarehttp://en.wikipedia.org/wiki/Requirementshttp://en.wikipedia.org/wiki/Software_engineering


3/28

way to uncover and capture the needs of the business and communicate those needs to a software

development team in a language and style that facilitates the software design process, producinga result that precisely solves the business problem. This is much easier said than done. All too

often the requirements process begins with a few key questions about the business need, and then

quickly moves to discussions about parts of the technology solution. Traditional requirements

documents are a confusing combination of business and technology language. As a result theyare time consuming for the careful reader, misunderstood by most, and generally ineffective as

communications devices

Requirements Analysis:

Requirements analysis insystems engineeringandsoftware engineering, encompasses thosetasks that go into determining the needs or conditions to meet for a new or altered product, takingaccount of the possibly conflictingrequirementsof the variousstakeholders, such as

beneficiaries or users.

Requirements analysis is critical to the success of a development project.Requirementsmust be

documented, actionable, measurable, testable, related to identified business needs oropportunities, and defined to a level of detail sufficient for system design. Requirements can bearchitectural,structural,behavioral,functional, andnon-functional.

The success of any new software project is critically dependent on the initial discovery orrequirements analysis phase of the project.

Here are some reasons requirements analysis is often treated as a separate projectdistinct fromdesign and implementation of a software system:

More accurate cost estimate.Its far easier to accurately estimate a development projectafter the requirements have been clearly established.

Better evaluation of the project. With an accurate estimate of cost and completion date,it is much easier to evaluate cost vs. benefit and to position the proposed system in a

companys overall strategic plan.

Higher-quality bidding from vendors. If you want competitive bids from software

development companies, a good requirements study is essential. Bids will be more

accurate because potential vendors have clear information on which to base theirproposals. In addition, because all bidders will be responding to the same written request,

your evaluation of their responses can be on a more apples to apples basis.

Leapfrog a generation of development. A well-executed requirements analysis oftenreveals opportunities to streamline or evolve existing business practices. Sometimes one

or two rounds of requirements analysis followed by a re-evaluation of objectives can help

you to skip a generation in-house developmentso you ultimately end up with version

2 of the desired system instead of version 1, saving considerable cost and time.

Steps in the Requirements Analysis Process :
http://en.wikipedia.org/wiki/Systems_engineeringhttp://en.wikipedia.org/wiki/Systems_engineeringhttp://en.wikipedia.org/wiki/Systems_engineeringhttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Requirementshttp://en.wikipedia.org/wiki/Requirementshttp://en.wikipedia.org/wiki/Requirementshttp://en.wikipedia.org/wiki/Stakeholder_(corporate)http://en.wikipedia.org/wiki/Stakeholder_(corporate)http://en.wikipedia.org/wiki/Stakeholder_(corporate)http://en.wikipedia.org/wiki/Requirementhttp://en.wikipedia.org/wiki/Requirementhttp://en.wikipedia.org/wiki/Requirementhttp://en.wikipedia.org/wiki/System_architecturehttp://en.wikipedia.org/wiki/System_architecturehttp://en.wikipedia.org/wiki/Structurehttp://en.wikipedia.org/wiki/Structurehttp://en.wikipedia.org/wiki/Structurehttp://en.wikipedia.org/wiki/Behaviorhttp://en.wikipedia.org/wiki/Behaviorhttp://en.wikipedia.org/wiki/Behaviorhttp://en.wikipedia.org/wiki/Functional_requirementshttp://en.wikipedia.org/wiki/Functional_requirementshttp://en.wikipedia.org/wiki/Functional_requirementshttp://en.wikipedia.org/wiki/Non-functional_requirementshttp://en.wikipedia.org/wiki/Non-functional_requirementshttp://en.wikipedia.org/wiki/Non-functional_requirementshttp://en.wikipedia.org/wiki/Non-functional_requirementshttp://en.wikipedia.org/wiki/Functional_requirementshttp://en.wikipedia.org/wiki/Behaviorhttp://en.wikipedia.org/wiki/Structurehttp://en.wikipedia.org/wiki/System_architecturehttp://en.wikipedia.org/wiki/Requirementhttp://en.wikipedia.org/wiki/Stakeholder_(corporate)http://en.wikipedia.org/wiki/Requirementshttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Systems_engineering


4/28

I. Fix system boundaries

This initial step helps in identifying how the new application integrates with the business

processes, how it fits into the larger picture and what its scope and limitations will be.

II. Identify the customer

In more recent times there has been a focus on identifying who the users or customers of anapplication are. Referred to broadly as the stake holders, these indicate the group or groups of

people who will be directly or indirectly impacted by the new application.

By defining in concrete terms who the intended user is, the Requirements Analyst knows in

advance where he has to look for answers. The Requirements Elicitation Process should focus on

the wish-list of this defined group to arrive at a valid requirements list.

III. Requirements elicitation

Information is gathered from the multiple stakeholders identified. The Requirements Analyst

draws out from each of these groups what their requirements from the application are and what

they expect the application to accomplish.Considering the multiple stakeholders involved, the list of requirements gathered in this manner

could run into pages. The level of detail of the requirements list is based on the number and size

of user groups, the degree of complexity of business processes and the size of the application.

a) Problems faced in Requirements Elicitation

Ambiguous understanding of processes

Inconsistency within a single process by multiple users

Insufficient input from stakeholders

Conflicting stakeholder interests

Changes in requirements after project has begun

A Requirements Analyst has to interact closely with multiple work-groups, often with conflicting

goals, to arrive at a bona fide requirements list. Strong communication and people skills along

with sound programming knowledge are prerequisites for an expert Requirements Analyst.

b) Tools used in Requirements Elicitation

Traditional methods of Requirements Elicitation included stakeholder interviews and focus

group studies. Other methods like flowcharting of business processes and the use of existing

documentation like user manuals, organizational charts, process models and systems or process

specifications, on-site analysis, interviews with end-users, market research and competitor

analysis were also used extensively in Requirements Elicitation.However current research in

Software Requirements Analysis Process has thrown up modern tools that are better equipped to

handle the complex and multilayered process of Requirements Elicitation. Some of the current

Requirements Elicitation tools in use are:

Prototypes

Use cases

Data flow diagrams


5/28

Transition process diagrams

User interfaces

IV. Requirements Analysis Process

Once all stakeholder requirements have been gathered, a structured analysis of these can be done

after modeling the requirements. Some of the Software Requirements Analysis techniques usedare requirements animation, automated reasoning, knowledge-based critiquing, consistency

checking, analogical and case-based reasoning.

V. Requirements Specification

Requirements, once elicited, modeled and analyzed should be documented in clear, unambiguous

terms. A written requirements document is critical so that its circulation is possible among all

stakeholders including the client, user-groups, the development and testing teams. Current

requirements engineering practices reveal that a well-designed, clearly documented

Requirements Specification is vital and serves as a:

Base for validating the stated requirements and resolving stakeholder conflicts, if any Contract between the client and development team

Basis for systems design for the development team

Bench-mark for project managers for planning project development lifecycle and goals

Source for formulating test plans for QA and testing teams

Resource for requirements management and requirements tracing

Basis for evolving requirements over the project life span

Software requirements specification involves scoping the requirements so that it meets the

customers vision. It is the result of collaboration between the end-user who is often not a

technical expert, and a Technical/Systems Analyst, who is likely to approach the situation in

technical terms.

The software requirements specification is a document that lists out stakeholders needs and

communicates these to the technical community that will design and build the system. The

challenge of a well-written requirements specification is to clearly communicate to both these

groups and all the sub-groups within.

To overcome this, Requirements Specifications may be documented separately as

User Requirements - written in clear, precise language with plain text and use cases, for the

benefit of the customer and end-user

System Requirements - expressed as a programming or mathematical model, addressing the

Application Development Team and QA and Testing Team.

Requirements Specification serves as a starting point for software, hardware and database design.

It describes the function (Functional and Non-Functional specifications) of the system,

performance of the system and the operational and user-interface constraints that will govern

system development.

VI. Requirements Management


6/28

Requirements Management is the comprehensive process that includes all aspects of software

requirements analysis and additionally ensures verification, validation and traceability of

requirements. Effective requirements management practices guarantee that all system

requirements are stated unambiguously, that omissions and errors are corrected and that evolving

specifications can be incorporated later in the project lifecycle.

Strengths and weaknesses :

Strengths:

Provides a checklist of requirements.

Provide a contract between the project sponsor(s) and developers.

For a large system can provide a high level description.

Weaknesses:

Such lists can run to hundreds of pages. It is virtually impossible to read such documentsas a whole and have a coherent understanding of the system.

Such requirements lists abstract all the requirements and so there is little context

This abstraction makes it impossible to see how the requirements fit or work

together.

This abstraction makes it difficult to prioritize requirements properly; while a list

does make it easy to prioritize each individual item, removing one item out of

context can render an entire use case or business requirement useless.

This abstraction increases the likelihood of misinterpreting the requirements; asmore people read them, the number of (different) interpretations of the envisioned

system increase.

This abstraction means that it's extremely difficult to be sure that you have themajority of the requirements. Necessarily, these documents speak in generality;

but the devil, as they say, is in the details.

These lists create a false sense of mutual understanding between the stakeholders and

developers.

These contract style lists give the stakeholders a false sense of security that the

developers must achieve certain things. However, due to the nature of these lists, they

inevitably miss out crucial requirements which are identified later in the process.Developers can use these discovered requirements to renegotiate the terms and conditions

in their favour.

These requirements lists are no help in system design, since they do not lend themselves

to application.

Data Flow Diagram (DFD) :


7/28

A data flow diagram (DFD) is a graphical representation of the "flow" of data through aninformation system. DFDs can also be used for thevisualizationofdata processing(structureddesign).On a DFD, data items flow from an external data source or an internal data store to an

internal data store or an external data sink, via an internal process.

A DFD provides no information about the timing of processes, or about whether processes willoperate in sequence or in parallel. It is therefore quite different from a flowchart, which shows

the flow of control through an algorithm, allowing a reader to determine what operations will beperformed, in what order, and under what circumstances, but not what kinds of data will be input

to and output from the system, nor where the data will come from and go to, nor where the data

will be stored (all of which are shown on a DFD). With a data flow diagram, users are able tovisualize how the system will operate, what the system will accomplish, and how the system will

be implemented. The old system's dataflow diagrams can be drawn up and compared with the

new system's data flow diagrams to draw comparisons to implement a more efficient system.

Data flow diagrams can be used to provide the end user with a physical idea of where the datathey input ultimately has an effect upon the structure of the whole system from order to dispatch

to report. How any system is developed can be determined through a data flow diagram.

There are several common modeling rules that I follow when creating DFDs:

1. All processes must have at least one data flow in and one data flow out.2. All processes should modify the incoming data, producing new forms of outgoing data.3. Each data store must be involved with at least one data flow.4. Each external entity must be involved with at least one data flow.5. A data flow must be attached to at least one process.

Advantages of data flow diagrams :

It gives further understanding of the interestedness of the system and sub-systems

It is useful from communicating current system knowledge to the user

Used as part of the system documentation files

Dataflow diagram helps to substantiate the logic underlining the dataflow of the

organization

It gives the summary of the system

DFD is very easy to follow errors and it is also useful for quick reference to the

development team for locating and controlling errors

Disadvantages of data flow diagram :

DFD is likely to take many alteration before agreement with the user

Physical consideration are usually left out

It is difficult to understand because it ambiguous to the user who have little or no

knowledge
http://en.wikipedia.org/wiki/Information_systemhttp://en.wikipedia.org/wiki/Information_systemhttp://en.wikipedia.org/wiki/Data_visualizationhttp://en.wikipedia.org/wiki/Data_visualizationhttp://en.wikipedia.org/wiki/Data_visualizationhttp://en.wikipedia.org/wiki/Data_processinghttp://en.wikipedia.org/wiki/Data_processinghttp://en.wikipedia.org/wiki/Data_processinghttp://en.wikipedia.org/wiki/Flowcharthttp://en.wikipedia.org/wiki/Flowcharthttp://en.wikipedia.org/wiki/Flowcharthttp://en.wikipedia.org/wiki/Flowcharthttp://en.wikipedia.org/wiki/Data_processinghttp://en.wikipedia.org/wiki/Data_visualizationhttp://en.wikipedia.org/wiki/Information_system


8/28

Data Flow Diagram Symbols :

Example of a Data Flow Diagram :


9/28

Above is an example of a data flow diagram created with Visual Case.Some important things to

note are:

The two links labelled "Student Information" have been mapped to the same data flow. If

you change the name of one, the other will automatically change. Most objects in Visual

Case can easily be mapped to other entities

The processes are all high level tasks that could be exploded into sub-data flow diagrams

that clarify and further specify the task

The data flows are all labelled with the information that is being transferred

Data Dictionary:

A data dictionary, ormetadatarepository, as defined in theIBM Dictionary of Computing, is a

"centralized repository of information about data such as meaning, relationships to other data,origin, usage, and format. The term may have one of several closely related meanings

pertaining todatabasesanddatabase management systems(DBMS):

adocumentdescribing a database or collection of databases an integralcomponentof aDBMSthat is required to determine its structure

a piece ofmiddlewarethat extends or supplants the native data dictionary of a DBMS

Documentation: Databaseusersandapplicationdevelopers can benefit from an authoritative

data dictionary document that catalogs the organization, contents, and conventions of one ormore databasesThis typically includes the names and descriptions of varioustablesandfieldsin

each database, plus additional details, like thetypeand length of eachdata element. There is no
http://en.wikipedia.org/wiki/Metadatahttp://en.wikipedia.org/wiki/Metadatahttp://en.wikipedia.org/wiki/Software_repositoryhttp://en.wikipedia.org/wiki/Software_repositoryhttp://en.wikipedia.org/wiki/Software_repositoryhttp://en.wikipedia.org/wiki/Databasehttp://en.wikipedia.org/wiki/Databasehttp://en.wikipedia.org/wiki/Databasehttp://en.wikipedia.org/wiki/Database_management_systemhttp://en.wikipedia.org/wiki/Database_management_systemhttp://en.wikipedia.org/wiki/Database_management_systemhttp://en.wikipedia.org/wiki/Documenthttp://en.wikipedia.org/wiki/Documenthttp://en.wikipedia.org/wiki/Documenthttp://en.wikipedia.org/wiki/Software_componenthttp://en.wikipedia.org/wiki/Software_componenthttp://en.wikipedia.org/wiki/Software_componenthttp://en.wikipedia.org/wiki/Database_management_systemhttp://en.wikipedia.org/wiki/Database_management_systemhttp://en.wikipedia.org/wiki/Database_management_systemhttp://en.wikipedia.org/wiki/Middlewarehttp://en.wikipedia.org/wiki/Middlewarehttp://en.wikipedia.org/wiki/Middlewarehttp://en.wikipedia.org/wiki/User_(computing)http://en.wikipedia.org/wiki/User_(computing)http://en.wikipedia.org/wiki/User_(computing)http://en.wikipedia.org/wiki/Application_softwarehttp://en.wikipedia.org/wiki/Application_softwarehttp://en.wikipedia.org/wiki/Application_softwarehttp://en.wikipedia.org/wiki/Table_(database)http://en.wikipedia.org/wiki/Table_(database)http://en.wikipedia.org/wiki/Table_(database)http://en.wikipedia.org/wiki/Column_(database)http://en.wikipedia.org/wiki/Column_(database)http://en.wikipedia.org/wiki/Column_(database)http://en.wikipedia.org/wiki/Data_typehttp://en.wikipedia.org/wiki/Data_typehttp://en.wikipedia.org/wiki/Data_typehttp://en.wikipedia.org/wiki/Data_elementhttp://en.wikipedia.org/wiki/Data_elementhttp://en.wikipedia.org/wiki/Data_elementhttp://en.wikipedia.org/wiki/Data_elementhttp://en.wikipedia.org/wiki/Data_typehttp://en.wikipedia.org/wiki/Column_(database)http://en.wikipedia.org/wiki/Table_(database)http://en.wikipedia.org/wiki/Application_softwarehttp://en.wikipedia.org/wiki/User_(computing)http://en.wikipedia.org/wiki/Middlewarehttp://en.wikipedia.org/wiki/Database_management_systemhttp://en.wikipedia.org/wiki/Software_componenthttp://en.wikipedia.org/wiki/Documenthttp://en.wikipedia.org/wiki/Database_management_systemhttp://en.wikipedia.org/wiki/Databasehttp://en.wikipedia.org/wiki/Software_repositoryhttp://en.wikipedia.org/wiki/Metadata


10/28


11/28

Advantages of a Data Dictionary : The primary advantage of creating an informative and well-

designed data dictionary is that it exudes clarity on the rest of the database documentation. Also,when a new user is introduced to the system, or a new administrator takes over the system,

identifying table structures and types becomes simpler. In scenarios involving large databases,

where it is not possible for an administrator to completely remember specific bits of information

about thousands of fields, a data dictionary becomes a crucial necessity

Decision Tree:

A decision tree is a decision support tool that uses a tree-likegraphormodelof decisions andtheir possible consequences, includingchanceevent outcomes, resource costs, andutility. It is

one way to display analgorithm. Decision trees are commonly used inoperations research,

specifically indecision analysis, to help identify a strategy most likely to reach agoal. Another

use of decision trees is as a descriptive means for calculatingconditional probabilities. When thedecisions or consequences are modelled by computational verb, then we call the decision tree a

computational verb decision tree.

Advantages :

Are simple to understand and interpret. People are able to understand decision tree

models after a brief explanation.

Have value even with little hard data. Important insights can be generated based onexperts describing a situation (its alternatives, probabilities, and costs) and their

preferences for outcomes.

Use awhite boxmodel. If a given result is provided by a model, the explanation for the

result is easily replicated by simple math.

Can be combined with other decision techniques.

A decision Tree consists of 3 types of nodes:-

1. Decision nodes - commonly represented by squares

2. Chance nodes - represented by circles3. End nodes - represented by triangles
http://en.wikipedia.org/wiki/Diagramhttp://en.wikipedia.org/wiki/Diagramhttp://en.wikipedia.org/wiki/Diagramhttp://en.wikipedia.org/wiki/Causal_modelhttp://en.wikipedia.org/wiki/Causal_modelhttp://en.wikipedia.org/wiki/Causal_modelhttp://en.wikipedia.org/wiki/Chancehttp://en.wikipedia.org/wiki/Chancehttp://en.wikipedia.org/wiki/Chancehttp://en.wikipedia.org/wiki/Utilityhttp://en.wikipedia.org/wiki/Utilityhttp://en.wikipedia.org/wiki/Utilityhttp://en.wikipedia.org/wiki/Algorithmhttp://en.wikipedia.org/wiki/Algorithmhttp://en.wikipedia.org/wiki/Algorithmhttp://en.wikipedia.org/wiki/Operations_researchhttp://en.wikipedia.org/wiki/Operations_researchhttp://en.wikipedia.org/wiki/Operations_researchhttp://en.wikipedia.org/wiki/Decision_analysishttp://en.wikipedia.org/wiki/Decision_analysishttp://en.wikipedia.org/wiki/Decision_analysishttp://en.wikipedia.org/wiki/Objective_(goal)http://en.wikipedia.org/wiki/Objective_(goal)http://en.wikipedia.org/wiki/Objective_(goal)http://en.wikipedia.org/wiki/Conditional_probabilityhttp://en.wikipedia.org/wiki/Conditional_probabilityhttp://en.wikipedia.org/wiki/Conditional_probabilityhttp://en.wikipedia.org/wiki/White_box_(software_engineering)http://en.wikipedia.org/wiki/White_box_(software_engineering)http://en.wikipedia.org/wiki/White_box_(software_engineering)http://en.wikipedia.org/wiki/White_box_(software_engineering)http://en.wikipedia.org/wiki/Conditional_probabilityhttp://en.wikipedia.org/wiki/Objective_(goal)http://en.wikipedia.org/wiki/Decision_analysishttp://en.wikipedia.org/wiki/Operations_researchhttp://en.wikipedia.org/wiki/Algorithmhttp://en.wikipedia.org/wiki/Utilityhttp://en.wikipedia.org/wiki/Chancehttp://en.wikipedia.org/wiki/Causal_modelhttp://en.wikipedia.org/wiki/Diagram


12/28

Structured English:

Structured English is the use of theEnglish languagewith the syntax ofstructured

programming. Thus structured English aims at getting the benefits of both the programminglogic and natural language. Program logic helps to attain precision while natural language helps

in getting the convenience of spoken languages.

Structured English or "pseudocode" consists of the following elements:

1. Operation statements written as English phrases executed from the top down2. Conditional blocks indicated by keywords such as IF, THEN, and ELSE3. Repetition blocks indicated by keywords such as DO, WHILE, and UNTIL

Use the following guidelines when writing Structured English:

1. Statements should be clear and unambiguous

2. Use one line per logical element3. All logic should be expressed in operational, conditional, and repetition blocks4. Logical blocks should be indented to show relationship5. Keywords should be capitalized

Examples of common keywords

START, BEGIN, END, STOP, DO, WHILE, DO WHILE, FOR, UNTIL, DO UNTIL, REPEAT,END WHILE, END UNTIL, END REPEAT, IF THEN, IF, ELSE, IF ELSE, END IF, THEN,

ELSE THEN, ELSE IF, SO, CASE, EQUAL, LT, LE, GT, GE, NOT, TRUE, FALSE, AND,

OR, XOR, GET, WRITE, PUT, UPDATE, CLOSE, OPEN, CREATE, DELETE, EXIT, FILE,

READ, EOF, EOT, WITH,RETURN

Example of Structured English :

A bank will grant loan under the following conditions

1. If a customer has an account with the bank and had no loan outstanding, loan will begranted.

2. If a customer has an account with the bank but some amount is outstanding from previousloans then loan will be granted if special approval is given.

3. Reject all loan applications in all other cases.

IF customer has a Bank Account THEN

IF Customer has no dues from previous account THEN

Allow loan facility

ELSEIF Management Approval is obtained THEN

Allow loan facility

ELSE
http://en.wikipedia.org/wiki/English_languagehttp://en.wikipedia.org/wiki/English_languagehttp://en.wikipedia.org/wiki/English_languagehttp://en.wikipedia.org/wiki/Structured_programminghttp://en.wikipedia.org/wiki/Structured_programminghttp://en.wikipedia.org/wiki/Structured_programminghttp://en.wikipedia.org/wiki/Structured_programminghttp://en.wikipedia.org/wiki/Structured_programminghttp://en.wikipedia.org/wiki/Structured_programminghttp://en.wikipedia.org/wiki/English_language


13/28

Reject

ENDIFENDIF

ELSE

Reject

ENDIF

Decision Tables:

Decision tables, likeflowchartsandif-then-elseandswitch-casestatements, associate conditionswith actions to perform, but in many cases do so in a more elegant way. A decision table is a

table with various conditions and their corresponding actions. A decision table is a table

composed of rows and columns, separated into four separate quadrants.

Conditions Condition Alternatives

Actions Action Entries

The upper left quadrant contains the conditions. The upper right quadrant contains the conditionrules ofr alternatives. The lower left quadrant contains the actions to be taken and the lower right

quadrant contains the action rules. The steps of building the concerned tables are given below.

1. Firstly figure out the most essential factors to be considered in making a decision.

This will identify the conditions involved in the decision. Only those conditions should

be selected which have the potential to either occur or not but partial occurrences are notpermissible.2. Determine the most possible steps that can take place under varying conditionsand not just under current condition. This step will identify the actions.

3. Calculate all the possible combinations of conditions.

For every N number of conditions there are 2*2*2. (N times) combinations to beconsidered.

4. Fill the decision rules in the table.

Entries in a decision table are filled as Y/N and action entries are generally marked as

"X". For the conditions that are immaterial a hyphen "-" is generally put. Decision table is

further simplified by eliminating and consolidating certain rules. Impossible rules areeliminated. There are certain conditions whose values do not affect the decision and

always result in the same action. These rules can be consolidated into a single rule.
http://en.wikipedia.org/wiki/Flowcharthttp://en.wikipedia.org/wiki/Flowcharthttp://en.wikipedia.org/wiki/Flowcharthttp://en.wikipedia.org/wiki/Conditional_(programming)http://en.wikipedia.org/wiki/Conditional_(programming)http://en.wikipedia.org/wiki/Conditional_(programming)http://en.wikipedia.org/wiki/Switch_statementhttp://en.wikipedia.org/wiki/Switch_statementhttp://en.wikipedia.org/wiki/Switch_statementhttp://en.wikipedia.org/wiki/Switch_statementhttp://en.wikipedia.org/wiki/Conditional_(programming)http://en.wikipedia.org/wiki/Flowchart


14/28

Feasibility Study:

A feasibility study looks at the viability of an idea with an emphasis on identifying potential

problems and attempts to answer one main question: Will the idea work and should you proceed

with it? Before you begin writing your business plan you need to identify how, where, and to

whom you intend to sell a service or product. You also need to assess your competition andfigure out how much money you need to start your business and keep it running until it is

established. Feasibility studies aim to objectively and rationally uncover the strengths and

weaknesses of the existing business or proposed venture, opportunities and threats as presented

by theenvironment, theresourcesrequired to carry through, and ultimately the prospects for

success. In its simplest term, the two criteria to judge feasibility arecostrequired andvalueto beattained.As such, a well-designed feasibility study should provide a historical background of the

business or project, description of theproductorservice, accounting statements, details of theoperationsandmanagement,marketing researchand policies, financial data, legal requirements

and tax obligations.Generally, feasibility studies precede technical development andproject

implementation.
http://en.wikipedia.org/wiki/Environmenthttp://en.wikipedia.org/wiki/Environmenthttp://en.wikipedia.org/wiki/Environmenthttp://en.wikipedia.org/wiki/Resourceshttp://en.wikipedia.org/wiki/Resourceshttp://en.wikipedia.org/wiki/Resourceshttp://en.wikipedia.org/wiki/Successhttp://en.wikipedia.org/wiki/Successhttp://en.wikipedia.org/wiki/Costhttp://en.wikipedia.org/wiki/Costhttp://en.wikipedia.org/wiki/Costhttp://en.wikipedia.org/wiki/Valuehttp://en.wikipedia.org/wiki/Valuehttp://en.wikipedia.org/wiki/Valuehttp://en.wikipedia.org/wiki/Producthttp://en.wikipedia.org/wiki/Producthttp://en.wikipedia.org/wiki/Producthttp://en.wikipedia.org/wiki/Service_(economics)http://en.wikipedia.org/wiki/Service_(economics)http://en.wikipedia.org/wiki/Service_(economics)http://en.wikipedia.org/wiki/Operationshttp://en.wikipedia.org/wiki/Operationshttp://en.wikipedia.org/wiki/Managementhttp://en.wikipedia.org/wiki/Managementhttp://en.wikipedia.org/wiki/Managementhttp://en.wikipedia.org/wiki/Marketing_researchhttp://en.wikipedia.org/wiki/Marketing_researchhttp://en.wikipedia.org/wiki/Marketing_researchhttp://en.wikipedia.org/wiki/Projecthttp://en.wikipedia.org/wiki/Projecthttp://en.wikipedia.org/wiki/Projecthttp://en.wikipedia.org/wiki/Projecthttp://en.wikipedia.org/wiki/Marketing_researchhttp://en.wikipedia.org/wiki/Managementhttp://en.wikipedia.org/wiki/Operationshttp://en.wikipedia.org/wiki/Service_(economics)http://en.wikipedia.org/wiki/Producthttp://en.wikipedia.org/wiki/Valuehttp://en.wikipedia.org/wiki/Costhttp://en.wikipedia.org/wiki/Successhttp://en.wikipedia.org/wiki/Resourceshttp://en.wikipedia.org/wiki/Environment


15/28

Five common factors (TELOS) :

Technology and system feasibility : The assessment is based on an outline design of system

requirements in terms of Input, Processes, Output, Fields, Programs, and Procedures. This can be

quantified in terms of volumes of data, trends, frequency of updating, etc. in order to estimate

whether the new system will perform adequately or not. Technological feasibility is carried outto determine whether the company has the capability, in terms of software, hardware, personnel

and expertise, to handle the completion of the project when writing a feasibility report, the

following should be taken to consideration:

A brief description of the business

The part of the business being examined

The human and economic factor

The possible solutions to the problems

Economic feasibility : Economic analysis is the most frequently used method for evaluating theeffectiveness of a new system. More commonly known as cost/benefit analysis, the procedure isto determine the benefits and savings that are expected from a candidate system and compare

them with costs. If benefits outweigh costs, then the decision is made to design and implement

the system. An entrepreneur must accurately weigh the cost versus benefits before taking an

action.Cost-based study: It is important to identify cost and benefit factors, which can becategorized as follows: 1. Development costs; and 2. Operating costs. This is an analysis of the

costs to be incurred in the system and the benefits derivable out of the system.Time-based study:

This is an analysis of the time required to achieve a return on investments.

Legal feasibility : Determines whether the proposed system conflicts with legal requirements,

e.g. a data processing system must comply with the local Data Protection Acts.

Operational feasibility : Operational feasibility is a measure of how well a proposed system

solves the problems, and takes advantage of the opportunities identified during scope definitionand how it satisfies the requirements identified in the requirements analysis phase of system

development.

Schedule feasibility : A project will fail if it takes too long to be completed before it is useful.

Typically this means estimating how long the system will take to develop, and if it can be

completed in a given time period using some methods like payback period. Schedule feasibility

is a measure of how reasonable the project timetable is. Given our technical expertise, are the

project deadlines reasonable? Some projects are initiated with specific deadlines. You need todetermine whether the deadlines are mandatory or desirable.
http://en.wikipedia.org/wiki/Cost-benefit_analysishttp://en.wikipedia.org/wiki/Cost-benefit_analysis


16/28

Other feasibility factors :

Market and real estate feasibility : Market Feasibility Study typically involves testing

geographic locations for a real estate development project, and usually involves parcels of realestate land. Developers often conduct market studies to determine the best location within a

jurisdiction, and to test alternative land uses for given parcels. Jurisdictions often require

developers to complete feasibility studies before they will approve a permit application for retail,commercial, industrial, manufacturing, housing, office or mixed-use project. Market Feasibility

takes into account the importance of the business in the selected area.

Resource feasibility : This involves questions such as how much time is available to build the

new system, when it can be built, whether it interferes with normal business operations, type and

amount of resources required, dependencies,

Cultural feasibility : In this stage, the project's alternatives are evaluated for their impact on thelocal and general culture. For example, environmental factors need to be considered and these

factors are to be well known. Further an enterprise's own culture can clash with the results of the

project.

Financial feasibility : In case of a new project,financial viability can be judged on the

following parameters:

Total estimated cost of the project

Financing of the project in terms of its capital structure, debt equity ratio and promoter's

share of total cost

Existing investment by the promoter in any other business

Projected cash flow and profitability

Feasibility Study Process :

1. Developing an understanding of a problem (or opportunity) in terms of its effect on theagency's mission and programs;

2. Developing an understanding of the organizational, managerial, and technicalenvironment within which a response to the problem or opportunity will be implemented;

3. Establishing programmatic and administrative objectives against which possibleresponses will be evaluated;

4. Preparing concise functional requirements of an acceptable response;

5. Identifying and evaluating possible alternative responses with respect to the establishedobjectives;
http://en.wikipedia.org/wiki/Culturehttp://en.wikipedia.org/wiki/Culture


17/28

6. Preparing an economic analysis for each alternative that meets the established objectivesand functional requirements;

7. Selecting the alternative that is the best response to the problem or opportunity;

8. Preparing a management plan for implementation of the proposed response; and

9. Documenting the results of the study in the form of a Feasibility Study Report (FSR).

Cost Benefit Analysis :

Cost benefit analysis is a term that refers both to:

helping to appraise, or assess, the case for aproject, programme or policy proposal;

an approach to making economic decisions of any kind.

Under both definitions the process involves, whether explicitly or implicitly, weighing the total

expected costs against the total expected benefits of one or more actions in order to choose thebest or most profitable option. The formal process is often referred to as either CBA (Cost-

Benefit Analysis) or BCA (Benefit-Cost Analysis).

Benefits and costs are often expressed in money terms, and are adjusted for thetime value of

money, so that all flows of benefits and flows of project costs over time (which tend to occur at

different points in time) are expressed on a common basis in terms of their present value.

Closely related, but slightly different, formal techniques includecost-effectivenessanalysis,

economic impact analysis, fiscal impact analysis andSocial Return on Investment(SROI)

analysis. The latter builds upon the logic of cost-benefit analysis, but differs in that it is explicitly

designed to inform the practical decision-making of enterprise managers and investors focused

on optimizing their social and environmental impacts. A cost benefit analysis is done to

determine how well, or how poorly, a planned action will turn out. Although a cost benefit

analysis can be used for almost anything, it is most commonly done on financial questions. Since

the cost benefit analysis relies on the addition of positive factors and the subtraction of negative

ones to determine a net result, it is also known as running the numbers. There are four basic steps

to performing a cost-benefit analysis:

Identify the project or program and alternatives

Describe quantitatively the inputs and outputs of each alternative

Estimate the value of the costs and benefits

Compare benefits and costs
http://en.wikipedia.org/wiki/Projecthttp://en.wikipedia.org/wiki/Projecthttp://en.wikipedia.org/wiki/Projecthttp://en.wikipedia.org/wiki/Time_value_of_moneyhttp://en.wikipedia.org/wiki/Time_value_of_moneyhttp://en.wikipedia.org/wiki/Time_value_of_moneyhttp://en.wikipedia.org/wiki/Time_value_of_moneyhttp://en.wikipedia.org/wiki/Cost-effectivenesshttp://en.wikipedia.org/wiki/Cost-effectivenesshttp://en.wikipedia.org/wiki/Cost-effectivenesshttp://en.wikipedia.org/wiki/Economic_impact_analysishttp://en.wikipedia.org/wiki/Economic_impact_analysishttp://en.wikipedia.org/wiki/Social_Return_on_Investmenthttp://en.wikipedia.org/wiki/Social_Return_on_Investmenthttp://en.wikipedia.org/wiki/Social_Return_on_Investmenthttp://en.wikipedia.org/wiki/Social_Return_on_Investmenthttp://en.wikipedia.org/wiki/Economic_impact_analysishttp://en.wikipedia.org/wiki/Cost-effectivenesshttp://en.wikipedia.org/wiki/Time_value_of_moneyhttp://en.wikipedia.org/wiki/Time_value_of_moneyhttp://en.wikipedia.org/wiki/Project


18/28

Strengths and Limitations :

Strengths

Compares costs and benefits using equal terms

Provides a clear indication of net cost or benefit of a specific area or regulation, helping

justify decisions at various levels Simplifies complex concepts and processes

Accepted by society more readily than other economic methods

Can be carried out at many levels (i.e., local, regional, national, international)

Limitations

Can be difficult to determine accurately the discount rate of future costs and benefits, aswell as indirect impacts

Often requiresnonmarket valuationmethods with varying degrees of complexity and

accuracy

Costs are easier to estimate than benefits Can be a time-consuming and expensive process

Does not always consider the source of the costs and benefits, needs to consider factorssuch as environmental justice and indirect impacts

Does not usually consider questions of environmental justice and how costs and benefits

are distributed across different groups

Process of Cost Benefit Analysis:

1.Defining the objectives and scope of the proposal/project

2.Clarifying the proposal options

3.Identifying the costs and benefits, both quantitative and qualitative

4.Discounting the future costs and benefits

5.Calculating the decision criteria

6.Performing sensitivity analysis and addressing issues of risk and uncertainty

7.Identifying the preferred option

8.Preparing the report.

Step 1: Define Objectives and Project Scope :

1 The Importance of ObjectivesProject identification and specification should be linked to CASA strategic objectiveseg,

as indicated in ministerial policy statements, annual reports and other relevant documents.Consistency with stated Government policy vis--vis airspace management is an important
http://www.hd.gov/HDdotGov/detail.jsp?ContentID=299http://www.hd.gov/HDdotGov/detail.jsp?ContentID=299http://www.hd.gov/HDdotGov/detail.jsp?ContentID=299http://www.hd.gov/HDdotGov/detail.jsp?ContentID=299


19/28

consideration, as well as how this fits with Australias international obligations and agreed

standards.

2 Proposal/Project Specification_ How will it meet objectives?

_ Will it involve new capital works/equipment acquisition?

_ Will there be a need to replace existing facilities/assets?_ Will there be a need to upgrade or enhance existing facilities?

_ What are the constraints?

_ Who is likely to be effected and how might impacts manifest?

Step 2: Identify Project Options :

1 Range of OptionsOptions are prepared to fulfil project objectives. Are there other ways to achieve the

same outcome? could be an important question to address. The range of feasible options

will vary with the nature of the problem. Tasks set at the strategic level may generate awide range of options. It will be necessary to determine the feasible options.

It will be important to determine whether there are there variations on one basic identified

option eg, variations in the design and operational concepts.When describing the options, the analyst should include:

_ A schedule for the project/proposal phase comprising a planning and development

schedule

_ The expected operational date of the option plus an operational schedule (eg, airspaceorganisation and structure, route structure, etc) and a replacement schedule (for

individual system components)

_ Type of equipment required if there are different levels of service to be considered_ Economic life of the key assets involved

_ A transition schedule (if appropriate)

_ Identification of who will be investing in the project (as well as to whom the case

needs to be justified to).The key question initially will be: What is the base case? Proposal options are evaluated

relative to a base case. CBA cannot be conducted without a base case. The base case provides the

benchmark against which the proposed project can be measured.Agreeing and defining the base case can be problematic and may benefit from use of a

VM workshop (as well as some internal discussion with technical experts within the

organisation proposing the change proposal/project).

Step 3: Identify Costs and Benefits :

All relevant costs and benefits must be included in the evaluation. Quantitative costs and

benefits are to be included in the discounted cash flow analysis, whilst qualitative costs

and benefits must be described and discussed as appropriate. It needs to be recognisedthat these can accrue to a wide range of parties and, given the particular situation, could

include some or all of the following: operators of commercial and GA aircraft, the military

(as an operator of aircraft and as a significant user of airspace for training purposes),passengers on commercial and other aircraft, and operators of air traffic and related

services. Identification of the likely impacted parties and the probable nature of such

impacts is a typical example of the sort of questions dealt with well in a VM workshop at anearly stage of the evaluation process.


20/28

1 Identify Quantitative Costs

The nature of the particular proposal being evaluated may be such that there may be anumber of project phases to consider.

The stages of development and the years in which costs are to be incurred needs to be

specified. There may be costs incurred during a planning phase (eg, R&D, testing of

various technologies and equipment applications, user community consultation) as well asin the implementation and operating phases of the change proposal or other initiative.

There may be a number of capital and other cost components incurred over time that need

to be included in the evaluation such as:_ Capital (or investment) items (eg, equipment or software)typically one-off

expenditures necessary for the project/proposal

_ Land acquisition and land restitution costs (including demolition, land clearance, sitepreparation, removal of redundant equipment/facilities, etc)

_ Construction costs (incl. professional fees)

_ Upgrade or refurbishment costs

_ Project management costs

_ Decommissioning costs_ Transition costs eg, parts of the existing/current system need to operated and

maintained during the transition period to a new system.

2 Identify Quantitative Benefits

There may be a range of benefits to be estimated and, where possible, quantified such as:_ Cost savings between options (eg, differences in operating and maintenance costs of

equipment and aircraft). Savings in operating costs such as reductions in fuel and oil

costs and flight time related operating costs (primarily crew and parts of maintenance

costs) are treated as benefits in CBA. These may also include cost savings for aircraftoperators due to a reduction in delays and reduced investment, operating and

maintenance costs associated with new technologies. Reductions in fuel and simpler

(more predictable) crew scheduling could result from a reduction in delays and these

will accrue benefits to aircraft operators._ Asset disposal.

_ Residual values (should be included in the DCF analysis as a negative cost item).

_ User benefits such as travel timesavings for passengers that could accrue due toaccommodating the optimum flight profile as desired by the operator, ie, optimum

routing, altitude and speed. Travel time benefits can also come from a reduction in

aircraft delays._ Improvements to the ratio of transit time to training time for military operations (training

sorties).

_ Incremental net revenue from changes in costs and charges.

Step 4: Discount Future Costs and Benefits :

1 DCF Analysis

Discountingwhat is it and why do it? As noted earlier, discounting is the reverse ofadding (or compounding) interest. It reduces the monetary value of future costs and

benefits back to a common time dimensionthe base year/date.

Discounting satisfies the view that people prefer immediate benefits over future benefits


21/28

(social time preference) and it also enables the opportunity cost to be reflected

(opportunity cost of capital).

2 Discounting ParametersThe analyst needs to determine the following when preparing to undertake the DCF

aspects of CBA:

_ The appropriate price year for cost estimates and the level of prevailing inflation_ Whether analysis of relative prices is necessary for some cost items (eg, labour costs)

_ What the base year (or discount year) is to be

_ What is to be the base/initial evaluation discount rate_ The evaluation period (or project period).

Step 5: Calculate the Decision Criteria :As noted previously, all costs and benefits over the evaluation period are discounted to a

present value to enable comparison between overall costs and benefits. This enables the

economic worth of the options to be determined relative to the base case.

It recommended that at a minimum the NPV is calculated and that this should be the key

decision criteria as this is considered to provide a better measure of societys wealthmaximisation than, for example, the internal rate of return of benefit-cost ratio. In other

words, in an unconstrained market, the option with the highest NPV provides the besteconomic return. Where there is a budget constraint however, the NPV/i ratio facilitates

capital rationing and indicates the highest return per dollar invested. It is therefore

possible that an option may well result in a lower NPV but a higher NPV/i ratio thananother option.

While the other measures can be readily calculated eg, IRR, BCR and payback period,

they should be utilised only as supplementary indicators.

Step 6: Sensitivity Analysis :Sensitivity analysis should be undertaken to test the robustness of results under different

scenarios, using different assumptions for various variables. It is a necessary part of any

investment appraisal as it can:_ Test the impact of using different discount rates (the agreed rate should be used with

sensitivity analysis two or three per cent points above and below the agreed rate)

_ Assess the possible impact of uncertainty_ Illustrate what would happen if the assumptions made about some variables proved to

be wrong and show how changes in the values of various factors affect the overall

costs or benefit of a given project_ Indicate the critical elements on which the positive outcome of the project depends.

Step 7: Identify Preferred Option :All relevant results and issues must be considered when identifying the preferred option.

In summary, the identification of the preferred option requires:1. The ranking of options by NPV and NPV/i and possibly BCR and IRR and other criteria

(eg, payback period) in the initial base evaluation.

2. The ranking of options by NPV and NPV/i in the subsequent sensitivity tests.


22/28

3. The weighting of costs and benefits which have only been quantified in physical units

or described in qualitative terms (intangibles) between options, even though this isinevitably subjective and somewhat arbitrary.

4. The overall ranking of options based on steps (1) to (3).

It is recommended to use NPV and NPVi for decision-making. Where a project is robust,

the ranking of options in the sensitivity tests will usually reflect the ranking of the initialevaluation. However, the ranking of options in the sensitivity tests may vary in comparison

to the initial evaluation ranking in the case of less robust proposals/projects.

When the unquantified and external costs and benefits are broadly similar in nature,ranking given by the cost-benefit criteria are usually sufficient and undisputed. However,

when there are significant differences in intangibles between options, a judgement

between competing options will need to be made. This may require an assessment ofwhether the net intangible benefits of the second ranked options can be valued at the

difference in NPV between it and the first ranked option.

Step 8: Prepare Report :

Full Evaluation Report

The final step of the CBA process is producing the report with the appraisal findings andrecommendations. This detailed report should include:

_ An Executive Summary of the evaluation, including the results and recommendations

_ The background to the evaluation, including

Reasons underpinning the proposal

A statement of why the initiative needs to be implemented immediately

Implications of deferring implementation of the proposal/project

The proposals/projects classification_ The objectives of the project/proposal

_ Evaluation considerations

Strategic issues particular to this proposal which will influence both the choice of

the options and the identification of appropriate costs and benefits_ A description of the options, including the base case

_ The identification of all costs and benefits, including the key assumptions and inputs

sourced from technical analysis undertaken to inform the CBA_ The annual cost and benefit streams

_ The results of the evaluation, including NPV, NVP/i and possibly BCR and IRR

_ The results of any sensitivity tests including specific risk modelling/analyses_ A discussion of qualitative factors (costs and benefits).

Software Requirements Specification:

A Software Requirements Specification (SRS) - arequirements specificationfor asoftware

system- is a complete description of the behavior of a system to be developed. It includes a set

ofuse casesthat describe all the interactions the users will have with the software. Use cases are

also known asfunctional requirements. In addition to use cases, the SRS also contains non-
http://en.wikipedia.org/wiki/Requirements_specificationhttp://en.wikipedia.org/wiki/Requirements_specificationhttp://en.wikipedia.org/wiki/Requirements_specificationhttp://en.wikipedia.org/wiki/Software_systemhttp://en.wikipedia.org/wiki/Software_systemhttp://en.wikipedia.org/wiki/Software_systemhttp://en.wikipedia.org/wiki/Software_systemhttp://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Functional_requirementshttp://en.wikipedia.org/wiki/Functional_requirementshttp://en.wikipedia.org/wiki/Functional_requirementshttp://en.wikipedia.org/wiki/Functional_requirementshttp://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Software_systemhttp://en.wikipedia.org/wiki/Software_systemhttp://en.wikipedia.org/wiki/Requirements_specification


23/28

functional (or supplementary) requirements.Non-functional requirementsare requirements

which impose constraints on the design or implementation (such asperformance engineeringrequirements,qualitystandards, or design constraints). A software requirements specification

(SRS) is a comprehensive description of the intended purpose and environment for software

under development. The SRS fully describes what the software will do and how it will be

expected to perform.

An SRS minimizes the time and effort required by developers to achieve desired goals and alsominimizes the development cost. A good SRS defines how anapplicationwill interact with

systemhardware, other programs and human users in a wide variety of real-world situations.

Parameters such as operating speed,response time,availability,portability, maintainability,footprint, security and speed of recovery from adverse events are evaluated.

An SRS is basically an organization's understanding (in writing) of a customer or potential

client's system requirements and dependencies at a particular point in time (usually) prior to any

actual design or development work. It's a two-way insurance policy that assures that both the

client and the organization understand the other's requirements from that perspective at a givenpoint in time.

The SRS document itself states in precise and explicit language those functions and capabilities a

software system (i.e., a software application, an eCommerce Web site, and so on) must provide,

as well as states any required constraints by which the system must abide. The SRS also

functions as a blueprint for completing a project with as little cost growth as possible. The SRS is

often referred to as the "parent" document because all subsequent project management

documents, such as design specifications, statements of work, software architecture

specifications, testing and validation plans, and documentation plans, are related to it.

It's important to note that an SRS contains functional and nonfunctional requirements only; itdoesn't offer design suggestions, possible solutions to technology or business issues, or any other

information other than what the development team understands the customer's system

requirements to be.

A well-designed, well-written SRS accomplishes four major goals:

1.It provides feedback to the customer. An SRS is the customer's assurance that the development

organization understands the issues or problems to be solved and the software behavior

necessary to address those problems. Therefore, the SRS should be written in natural language

(versus a formal language, explained later in this article), in an unambiguous manner that may

also include charts, tables, data flow diagrams, decision tables, and so on.

2.It decomposes the problem into component parts. The simple act of writing down software

requirements in a well-designed format organizes information, places borders around the

problem, solidifies ideas, and helps break down the problem into its component parts in an

orderly fashion.
http://en.wikipedia.org/wiki/Non-functional_requirementshttp://en.wikipedia.org/wiki/Non-functional_requirementshttp://en.wikipedia.org/wiki/Non-functional_requirementshttp://en.wikipedia.org/wiki/Performance_engineeringhttp://en.wikipedia.org/wiki/Performance_engineeringhttp://en.wikipedia.org/wiki/Performance_engineeringhttp://en.wikipedia.org/wiki/Quality_(business)http://en.wikipedia.org/wiki/Quality_(business)http://en.wikipedia.org/wiki/Quality_(business)http://whatis.techtarget.com/definition/0,289893,sid9_gci213024,00.htmlhttp://whatis.techtarget.com/definition/0,289893,sid9_gci213024,00.htmlhttp://whatis.techtarget.com/definition/0,289893,sid9_gci213024,00.htmlhttp://whatis.techtarget.com/definition/0,289893,sid9_gci211585,00.htmlhttp://whatis.techtarget.com/definition/0,289893,sid9_gci211585,00.htmlhttp://whatis.techtarget.com/definition/0,289893,sid9_gci211585,00.htmlhttp://whatis.techtarget.com/definition/0,289893,sid9_gci212228,00.htmlhttp://whatis.techtarget.com/definition/0,289893,sid9_gci212228,00.htmlhttp://whatis.techtarget.com/definition/0,289893,sid9_gci212228,00.htmlhttp://whatis.techtarget.com/definition/0,289893,sid9_gci212896,00.htmlhttp://whatis.techtarget.com/definition/0,289893,sid9_gci212896,00.htmlhttp://whatis.techtarget.com/definition/0,289893,sid9_gci212896,00.htmlhttp://whatis.techtarget.com/definition/0,289893,sid9_gci213489,00.htmlhttp://whatis.techtarget.com/definition/0,289893,sid9_gci213489,00.htmlhttp://whatis.techtarget.com/definition/0,289893,sid9_gci213489,00.htmlhttp://whatis.techtarget.com/definition/0,289893,sid9_gci212809,00.htmlhttp://whatis.techtarget.com/definition/0,289893,sid9_gci212809,00.htmlhttp://whatis.techtarget.com/definition/0,289893,sid9_gci212809,00.htmlhttp://whatis.techtarget.com/definition/0,289893,sid9_gci212140,00.htmlhttp://whatis.techtarget.com/definition/0,289893,sid9_gci212140,00.htmlhttp://whatis.techtarget.com/definition/0,289893,sid9_gci212140,00.htmlhttp://whatis.techtarget.com/definition/0,289893,sid9_gci212809,00.htmlhttp://whatis.techtarget.com/definition/0,289893,sid9_gci213489,00.htmlhttp://whatis.techtarget.com/definition/0,289893,sid9_gci212896,00.htmlhttp://whatis.techtarget.com/definition/0,289893,sid9_gci212228,00.htmlhttp://whatis.techtarget.com/definition/0,289893,sid9_gci211585,00.htmlhttp://whatis.techtarget.com/definition/0,289893,sid9_gci213024,00.htmlhttp://en.wikipedia.org/wiki/Quality_(business)http://en.wikipedia.org/wiki/Performance_engineeringhttp://en.wikipedia.org/wiki/Non-functional_requirements


24/28

3. serves as an input to the design specification. As mentioned previously, the SRS serves as the

parent document to subsequent documents, such as the software design specification and

statement of work. Therefore, the SRS must contain sufficient detail in the functional system

requirements so that a design solution can be devised.

4.It serves as a product validation check. The SRS also serves as the parent document for testingand validation strategies that will be applied to the requirements for verification.

Benefits of SRS:

Establish the basis for agreement between the customers and the suppliers on what the softwareproduct is to do. The complete description of the functions to be performed by the software

specified in the SRS will assist the potential users to determine if the software specified meets

their needs or how the software must be modified to meet their needs. [NOTE: We use it as the

basis of our contract with our clients all the time].

Reduce the development effort. The preparation of the SRS forces the various concerned groupsin the customers organization to consider rigorously all of the requirements before design beginsand reduces later redesign, recoding, and retesting. Careful review of the requirements in the

SRS can reveal omissions, misunderstandings, and inconsistencies early in the development

cycle when these problems are easier to correct.

Provide a basis for estimating costs and schedules. The description of the product to be

developed as given in the SRS is a realistic basis for estimating project costs and can be used toobtain approval for bids or price estimates. [NOTE: Again, we use the SRS as the basis for our

fixed price estimates]

Provide a baseline for validation and verification. Organizations can develop their validation andVerification plans much more productively from a good SRS. As a part of the development

contract, the SRS provides a baseline against which compliance can be measured. [NOTE: We

use the SRS to create the Test Plan].

Facilitate transfer.The SRS makes it easier to transfer the software product to new users or newmachines. Customers thus find it easier to transfer the software to other parts of their

organization, and suppliers find it easier to transfer it to new customers.

Serve as a basis for enhancement. Because the SRS discusses the product but not the project that

developed it, the SRS serves as a basis for later enhancement of the finished product. The SRS

may need to be altered, but it does provide a foundation for continued production evaluation.[NOTE: This is often a major pitfallwhen the SRS is not continually updated with changes]

The basic issues that the SRS writer(s) shall address are the following:

a) Functionality. What is the software supposed to do?

b) External interfaces. How does the software interact with people, the systemshardware, other hardware, and other software?


25/28

c) Performance. What is the speed, availability, response time, recovery time of various

software functions, etc.?d) Attributes. What are the portability, correctness, maintainability, security, etc.

considerations?

e) Design constraints imposed on an implementation. Are there any required standards in

effect, implementation language, policies for database integrity, resource limits, operatingenvironment(s) etc.?

Characteristics of SRS:

a) Correctb) Unambiguous

c) Complete

d) Consistent

e) Ranked for importance and/or stabilityf) Verifiable

g) Modifiableh) Traceable

Correct - This is like motherhood and apple pie. Of course you want the specification to becorrect. No one writes a specification that they know is incorrect. We like to say - "Correct andEver Correcting." The discipline is keeping the specification up to date when you find things that

are not correct.

Unambiguous - An SRS is unambiguous if, and only if, every requirement stated therein has

only one interpretation. Again, easier said than done. Spending time on this area prior toreleasing the SRS can be a waste of time. But as you find ambiguities - fix them.

Complete - A simple judge of this is that is should be all that is needed by the software designers

to create the software.

Consistent - The SRS should be consistent within itself and consistent to its reference

documents. If you call an input "Start and Stop" in one place, don't call it "Start/Stop" in another.

Ranked for Importance - Very often a new system has requirements that are really marketing

wish lists. Some may not be achievable. It is useful provide this information in the SRS.

Verifiable - Don't put in requirements like - "It should provide the user a fast response." Another

of my favorites is - "The system should never crash." Instead, provide a quantitative requirementlike: "Every key stroke should provide a user response within 100 milliseconds."

Modifiable - Having the same requirement in more than one place may not be wrong - but tendsto make the document not maintainable.


26/28

Traceable - Often, this is not important in a non-politicized environment. However, in most

organizations, it is sometimes useful to connect the requirements in the SRS to a higher leveldocument. Why do we need this requirement?

How to write a SRS:

1.If your organization does not have a standard Software Requirements Specifications documenttemplate, create one now. Please see the Resources section below for some links to templates I

found onthe internet.

2.Meet with the subject matter experts / clients to gather the requirements.

3.Define the functions of the software.

4.Create use cases for the major sub processes. For example, if you are designing an order entry

system. Use cases would consist of creating a new order, modifying an existing order, customer

order search, etc.

5.Define the user interface.

6.Define any other interfaces such as hardware interfaces or other software system interfaces.

7.Define the process flow.

8.Determine any specific business rules.

9.Define the performance specification.

10.Create any diagrams needed to illustrate process flow or elaborate on key requirements.

11.Compile the SRS document and have all necessarypartiesreview or sign off on it.

How to Write a Software Requirements

Specifications (SRS) DocumentBy eHow Contributor , last updated August 01, 2011
http://www.ehow.com/internet/http://www.ehow.com/internet/http://www.ehow.com/internet/http://www.ehow.com/weddings-and-parties/http://www.ehow.com/weddings-and-parties/http://www.ehow.com/weddings-and-parties/http://www.ehow.com/weddings-and-parties/http://www.ehow.com/internet/


27/28

Software Requirements - SRS

Professional software developers must go through a software requirements gatheringprocess at the beginning of software development projects of any meaningful size. The endproduct of that project phase is a document commonly referred to as a SoftwareRequirements Specification, or SRS. It's usually the first project milestone or deliverable.The importance of this document cannot be understated. Its foremost function is to recordthe client's business needs and requirements in written form and become the foundation

for the rest of the software development process. Once these requirements are compiled,the document becomes the record of both the client's and developer's understanding ofwhat the software should accomplish. Usually the client reviews and signs the SRS, thusbeginning the full software design and development phase. By taking the high level steps

involved, you can write an SRS document.1.

o 1If your organization does not have a standard Software Requirements Specificationsdocument template, create one now (see Resources for links to templates).

o 2Meet with the subject matter experts/clients to gather the requirements.

o 3Define the functions of the software.

o 4Create use cases for the major sub-processes. For example, if you're designing an orderentry system, use cases would consist of creating a new order, modifying an existing orderand a customer order search.

o 5


28/28

Define the user interface.

o 6Define any other interfaces such as hardware interfaces or other software system interfaces.

o 7Define the process flow.

o 8Determine any specific business rules.

o 9Define the performance specification.

o 10Create any diagrams needed to illustrate the process flow or elaborate on key requirements.

o 11Compile the SRS document and have all necessary parties review or sign it

Unit 2 Software Requirements Complt

Documents

Transcript of Unit 2 Software Requirements Complt