Software Requirement Engineering

1
Software Requirement Engineering

• Naman Modi

2
Outline

• RE Def
• The Challenge of RE
• Scope of Project Failure
• Ambiguity
• The RE Process
• The Software Requirements Document
• Requirement Growth

3
RE Def

• A definition of RE
• RE is concerned with identifying the purpose of
  a software system
• and the contexts in which it will be used.
• Hence, RE acts as the bridge between
• the real world needs of users, customers, and
  other constituencies affected by a software
  system
• and the capabilities and opportunities
  afforded by software-intensive
  technologies.
• RE01 call for papers see www.re01.org

4
But what is a requirement?

• A condition or capability that must be met or
  possessed by a system or system component to
  satisfy a contract, standard, specification, or
  other formally imposed document
• The set of all requirements forms the basis for
  subsequent development of the system or system
  component.
• IEEE Std

5
Why RE

• "The hardest single part of building a software
  system is deciding precisely what to build. No
  other part of the conceptual work is as difficult
  as establishing the detailed technical
  requirements, including all the interfaces to
  people, to machines, and to other software
  systems. No other part of the work so cripples
  the resulting system if done wrong. No other part
  is more difficult to rectify later".
• (F. Brooks, "No Silver Bullet", IEEE
  Computer, 1987)
• After fifty years of industry
  experience, software projects still struggle to
  gather, document and manage their product
  requirements. Lack of user input, incomplete or
  changing requirements are the major reasons why
  so many IT projects struggle or fail.
• Karl Wiegers, 2003, Software Requirements,
• Second Edition, Microsoft Press.

6
Scope of Software Project Failures

• WHY PROJECTS FAIL
  
• 1. Incomplete Requirements
  13.1
• 2. Lack of user involvement 12.4
• 3. Lack of resources 10.6
• 4. Unrealistic Expectations 9.9
• 5. Lack of executive support 9.3
• 6. Changing requirements 8.7
• 7. Lack of planning 8.1
• 8. Didnt need it any longer 7.5
• 9. Lack of IT management 6.2
• 10. Technology illiteracy 4.3
• Jim Johnson, The Standish Group International
  Project Leadership
• Conference, May 1995, Chicago
• http//www.standishgroup.com/sample_research/

7
Recipe for Success

• WHY PROJECTS SUCCEED
• 1. Executive support 18
• 2. User involvement 16
• 3. Experienced project manager 14
• 4. Clear business objectives 12
• 5. Minimized scope 10
• 6. Standard software infrastructure 8
• 7. Firm basic requirements 6
• 8. Formal methodology 6
• 9. Reliable estimates 5
• 10. Other criteria 5
• Jim Johnson et al., Collaborating on Project
  Success ,
• SoftwareMag.com Feb 2001,
• http//www.softwaremag.com/archive/2001feb/Coll
  aborativeMgt.html
• http//www.standishgroup.com/sample_research/PD
  Fpages/extreme_chaos.pdf

8
Ambiguity in Stating Requirements

• Missing requirements
• (E.g. structure, functions, physical envt.)
• Ambiguous words
• E.g., small does not adequately specify the
  size of the group
• -E.g., group implies that the people will
  interact, but its not clear how
• Introduced elements
• E.g., Structure-create a means not design a
  structure

9
Relative Cost to Fix an Error

• Phase in Which Found Cost Ratio
• Requirements 1
• Design 3-6
• Coding 10
• Development testing 15-40
• Acceptance testing 30-70
• Operation 40-1000
• Boehms analysis of 63 s/w development projects
  (IBM, GTE, TRW, etc.) to
• Determine ranges in cost for errors created by
  false assumptions in reqts phase
• But not detected till later phases

10
Sources RE Difficulties

• RE is where informal meets formal (M.Jackson)
• Many requirements are created, not found.
• Users, buyers, even developers may be unknown.
• Stakeholders have conflicting objectives.
• Multiple views exist
• Inconsistency must be tolerated, for a while.
• Requirements evolve during and after development.

11
Guiding Principles for Requirements Engineering

• Understand the problem before you begin to create
  the analysis model. (ex. long wait for elevators)
• Develop prototypes that enable a user to
  understand how human-machine interaction will
  occur. (vs. waterwall model)
• Record the origin of (traceability) and reason
  for every requirement (rationale). (requirement
  -gt business problem)
• Use multiple views of requirements.
• Prioritize requirements.
• Work to eliminate ambiguity. Davis, 1995

12
The RE Process

• The processes used for RE vary widely depending
  on the application domain, the people involved
  and the organisation developing the requirements.
• However, there are a number of generic activities
  common to all processes
• Modeling
• Requirements elicitation analysis
• Requirement Specification
• Requirements validation
• Requirements management.

13
The RE Process
Ian Sommerville 2004 SE,7th Edition, Chp 7
14
The RE Process

•  Requirements analysis elicitation
• Find out what system stakeholders require from
  the system (existing systems, potential users,
  system models, system prototypes)
• Modeling
• - After the task of requirements elicitation,
  the analyst will build the model that represents
  the problem domain. Modeling the requirements
  makes easy to analyze them. Basically, the
  analyst studies the models he has built to
  detecting problems (i.e. inconsistency) or the
  problem to integrate new models with the rest of
  the requirements.
• Requirements specification
• Define the requirements in detail (unambiguous
  to the developers)

15

• Analysis vs. Specification

• Analysis is the process of understanding the
  problem and the requirements for a solution
• Specification is the process of describing what a
  system will do
• It will help clarify what you think
• It is necessary to communicate with your
  customers
• It is necessary to communicate with your team
  members
• It could form the basis for a contractual
  relationship
• Analysis leads to Specification --they are not
  the same

16

The RE Process

• Goals for Specifications
• Completeness
• Comprehensibility
• Testability
• Consistency
• Unambiguity
• Writeability
• Modifiability
• Implementability

17

• The RE Process

• Requirements Validation
• Demonstrating that the requirements define the
  system that the customer really wants
• Requirements error costs are high so validation
  is very important
• Fixing a requirements error after delivery may
  cost up to 100 times the cost of fixing an
  implementation error
• Prototyping is an important technique of
  requirements validation

18
The RE Process

• Requirements Checking
• Validity
• Does the system provide the functions which
  best support the customers needs?
• Consistency
• Are there any requirements conflicts?
• Completeness
• -Are all functions required by the customer
  included?
• Realism
• Can the requirements be implemented given
  available budget and technology

19
The RE Process

• Requirements Review Checks
• Verifiability
• Is the requirement realistically testable?
• Comprehensibility
• Is the requirement properly understood?
• Traceability
• Is the origin of the requirement clearly
  stated?
• Adaptability
• Can the requirement be changed without a large
  impact on other requirements?

20
What goes into an SRD?
Project Title General Description of
System Concept Model of Current Operations
Model of Planned Operations List of Required
Functions Data Elements Reqd Inputs
Outputs Design Constraints Implementation
Constraints Specific formats are 1) IEEE Std.
1233, 1998 Edition IEEE Guide for Developing
System Requirements Specifications (SyRS)
http//cs.wwc.edu/aabyan/435/Forms/RAD.html 2)
IEEE Std. 830-1998 IEEE Recommended Practice for
Software Requirements Specifications (SRS)
http//cs.wwc.edu/aabyan/435/Forms/SRS.html
21
Requirements Growth Source Adapted from Davis
1988, pp1453-1455

• Daviss model
• User needs evolve continuously
• Represent this as a graph showing growth of needs
  over time
• May not be linear or continuous (hence no scale
  shown)
• Traditional development always lags behind
  needs growth
• first release implements only part of the
  original requirements
• functional enhancement adds new Functionality
• eventually, further enhancement becomes too
  costly, and a replacement is planned
• the replacement also only implements part of its
  requirements, and so on...

22

• Summary

• Its very difficult to formulate a complete and
  consistent requirements specification
• A requirements definition, a requirements
  specification and a software specification are
  ways of specifying software for different types
  of reader
• The requirements document is a description for
  customers and developers
• Requirements errors are usually very expensive
  to correct after system delivery
• Reviews involving client and contractor staff
  are used to validate the system requirements

23

• References

Michael Jackson Software Requirements
Specifications, a lexicon of practice, principles
and prejudices. Addison-Wesley, 1995
B. A. Nuseibeh and S. M. Easterbrook,
"Requirements Engineering A Roadmap", In A. C.
W. Finkelstein (ed) The Future of Software
Engineering ACM Press http//www.cs.toronto.edu/
sme/papers/2000/ICSE2000.pdf Book reviews
at http//easyweb.easynet.co.uk/iany/reviews/rev
iews.htm Website maintained by R.S. Pressman
Associates, Inc on RE http//www.rspa.com/reflib/R
equirementsEngr.html
24

• References

Requirement Engineering Newsletter http//polar
is.umuc.edu/skerby/help/wbib_swe.htm Presentatio
n by Dr. Annie I. Antón on Requirement
Engineering http//ecommerce.ncsu.edu/studio/lectu
res/RE_2006.pdf 12th IEEE International
Requirement Engineering Conference http//www.re04
.org/ Paper by Parastoo Mohagheghi Reidar
Conradi http//www.idi.ntnu.no/grupper/su/publ/par
astoo/step05-21aug05.pdf Paper The Software
Requirement Engineering by John
Frankovich http//sern.ucalgary.ca/courses/seng/62
1/W97/johnf/reqeng.htm International Workshop
on RE http//www.ifi.unizh.ch/groups/req/IWRE/abst
racts.html
25
Feedback Questions??