unit 2 software requirements complt
TRANSCRIPT
-
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).
-
7/31/2019 Unit 2 Software Requirements Complt
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 -
7/31/2019 Unit 2 Software Requirements Complt
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 -
7/31/2019 Unit 2 Software Requirements Complt
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
-
7/31/2019 Unit 2 Software Requirements Complt
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
-
7/31/2019 Unit 2 Software Requirements Complt
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/31/2019 Unit 2 Software Requirements Complt
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 -
7/31/2019 Unit 2 Software Requirements Complt
8/28
Data Flow Diagram Symbols :
Example of a Data Flow Diagram :
-
7/31/2019 Unit 2 Software Requirements Complt
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 -
7/31/2019 Unit 2 Software Requirements Complt
10/28
-
7/31/2019 Unit 2 Software Requirements Complt
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 -
7/31/2019 Unit 2 Software Requirements Complt
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 -
7/31/2019 Unit 2 Software Requirements Complt
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 -
7/31/2019 Unit 2 Software Requirements Complt
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 -
7/31/2019 Unit 2 Software Requirements Complt
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 -
7/31/2019 Unit 2 Software Requirements Complt
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 -
7/31/2019 Unit 2 Software Requirements Complt
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 -
7/31/2019 Unit 2 Software Requirements Complt
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 -
7/31/2019 Unit 2 Software Requirements Complt
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.
-
7/31/2019 Unit 2 Software Requirements Complt
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
-
7/31/2019 Unit 2 Software Requirements Complt
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.
-
7/31/2019 Unit 2 Software Requirements Complt
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 -
7/31/2019 Unit 2 Software Requirements Complt
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 -
7/31/2019 Unit 2 Software Requirements Complt
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?
-
7/31/2019 Unit 2 Software Requirements Complt
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.
-
7/31/2019 Unit 2 Software Requirements Complt
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/ -
7/31/2019 Unit 2 Software Requirements Complt
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
-
7/31/2019 Unit 2 Software Requirements Complt
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