Requirements elicitation is the process of discovering, reviewing, documenting, and understanding the user's needs and constraints for the system. Requirements analysis is the process of refining the user's needs and constraints. Requirements specification is the process of documenting the user's needs and constraints clearly and precisely. Requirements verification is the process of ensuring that the system requirements are complete, correct, consistent, and clear. Requirements management is the process of scheduling, coordinating, and documenting the requirements engineering activities (that is, elicitation, analysis, specification, and verification)

1. Requirements Engineering Activities
Requirements
Elicitation
Requirements
Analysis and
Negotiation
Requirements
Specification
Requirements
Validation
User Needs,
Domain Information,
Existing System
Information, Regulations,
Standards, Etc.
Requirements
Document
Agreed
Requirements

2. 2
Requirements Elicitation
• Determining the system requirements through
consultation with stakeholders, from system
documents, domain knowledge, and market
studies
• Requirements acquisition or requirements
discovery

3. 3
Requirements Analysis and Negotiation - 1
• Understanding the relationships among various
customer requirements and shaping those
relationships to achieve a successful result
• Negotiations among different stakeholders and
requirements engineers
Requirements analysis and negotiation
activity is performed by

4. 4
Requirements Analysis and Negotiation - 2
• Incomplete and inconsistent information needs to be tackled here
• Some analysis and negotiation needs to be done on account of
budgetary constraints

5. 5
Requirements Specification
• Building a tangible model of requirements using
natural language and diagrams
• Building a representation of requirements that can
be assessed for correctness, completeness, and
consistency
Requirements specification includes

6. 6
Requirements Document
• Detailed descriptions of the required software system
in form of requirements is captured in the
requirements document
• Software designers, developers and testers are the
primary users of the document

7. 7
Requirements Validation
• It involves reviewing the requirements model for consistency and
completeness
• This process is intended to detect problems in the requirements
document, before they are used as a basis for the system
development

8. Requirement Validation
• Certifies that the requirements document is an
acceptable description of the system to be
implemented
• Checks a requirement document for
• Completeness and consistency
• Conformance to standards
• Requirements conflicts
• Technical errors
• Ambiguous requirements

9. Analysis and Validation
• Analysis works with raw requirements as elicited
from the system stakeholders
• “Have we got the right requirements” is the key
question to be answered at this stage
• Validation works with a final draft of the
requirements document i.e., with negotiated and
agreed requirements
• “Have we got the requirements right” is the key
question to be answered at this stage
• http://reqtest.com/requirements-blog/do-requirements-management-right-from-
the-start-who-does-what-and-why/

10. • Requirements validation is the process of certifying
the requirements model for correctness against the
user's intention
• As such requirements validation helps to do the right
thing in contrast with the careful following of a
modeling approach which helps in doing the thing
right.

11. Validation Inputs and Outputs
Requirements
Validation
Requirements
document
Organizational
knowledge
Organizational
standards
List of problems
Agreed actions

12. 12
Requirements Document
• Should be a complete version of the document, not an unfinished
draft. Formatted and organized according to organizational standards

13. 13
Organizational Knowledge
• Knowledge, often implicit, of the organization
which may be used to judge the realism of the
requirements

14. 14
Organizational Standards
• Local standards e.g. for the organization of the requirements
document

15. 15
List of Problems
• List of discovered problems in the requirements document

16. 16
Agreed Actions
• List of agreed actions in response to requirements problems. Some
problems may have several corrective actions; some problems may
have no associated actions

17. 17
Requirements Reviews
• A group of people read and analyze the
requirements, look for problems, meet and discuss
the problems and agree on actions to address
these problems

18. Importance of Requirement Validation
• It cost approximately 100 times more to correct
customer reported requirement error than to
correct an error during requirement development.
• It took an average 30 minutes to fix an error
discovered during the requirement phase while it
took 5-17 hours to identify same defect during
system testing.
• In one analysis of 34 safety incidents, “44% had
inadequate specification as their primary cause

19. Types of Testing
• Acceptance testing is based on user requirements
• System testing is based on functional requirements
• Integration testing is based on system architecture
• Unit testing is based on module design

20. Requirement Validation Techniques
• Reviews
• Inspections
• Prototyping
• User manual development
• Model validation
• Requirements testing

21. Reviewing Requirements
• Reviewing requirement documents is a
technique used for identifying ambiguous or
unverifiable requirements. Informal and formal
reviews approaches are used for reviewing
requirements
• Informal reviews are used to educate other
peoples about the product and collecting
unstructured feedback
• Formal reviews follows well defined process
and produce report that identifies the
material, the reviewers and the judgment
of review team. The best type of formal
review is the inspection.

22. Formal Review Process
Plan review
Distribute
documents
Prepare for
review
Hold review
meeting
Follow-up
actions
Revise
documents

23. 23
Review Activities - 1
• Plan review
• The review team is selected and a time and place for the
review meeting is chosen
• Distribute documents
• The requirements document is distributed to the review
team members

24. 24
Review Activities - 2
• Prepare for review
• Individual reviewers read the requirements to find conflicts, omissions,
inconsistencies, deviations from standards and other problems
• Hold review meeting
• Individual comments and problems are discussed and a set of actions to
address the problems is agreed

25. 25
Review Activities - 3
• Follow-up actions
• The chair of the review checks that the agreed actions have been carried
out
• Revise document
• The requirements document is revised to reflect the agreed actions. At this
stage, it may be accepted or it may be re-reviewed

26. 26
Problem Actions
• Requirements clarification
• Missing information
• Requirements conflict
• Unrealistic requirement

27. 27
Requirements Clarification
• The requirement may be badly expressed or may have accidentally
omitted information which has been collected during requirements
elicitation

28. 28
Missing Information
• Some information is missing from the requirements document. It is
the responsibility of the requirements engineers who are revising the
document to discover this information from system stakeholders

29. 29
Requirements Conflict
• There is a significant conflict between requirements. The
stakeholders involved must negotiate to resolve the conflict

30. 30
Unrealistic Requirement
• The requirement does not appear to be implement-able with the
technology available or given other constraints on the system.
Stakeholders must be consulted to decide how to make the
requirement more realistic

31. 31
Pre-review Checking - 1
• Reviews are expensive because they involve a number of people
spending time reading and checking the requirements document

32. 32
Pre-review Checking - 2
• This expense can be reduced by using pre-review checking where one
person checks the document and looks for straightforward problems
such as missing requirements, lack of conformance to standards,
typographical errors, etc.
• Document may be returned for correction or the list of problems
distributed to other reviewers

33. Pre-review Checking Stages
Check
document
structure
Check
document
completeness
Check document
against
standards
Run
automatic
checkers
Requirements
document
Problems
report

34. Inspection Process
• Software inspection can detect almost 50% to
90% defects
• Inspection is costly and time consuming
• Inspection is a well defined multi-stage process.
It involves a small team of trained participants
who carefully examine a work product for defects
and improvement opportunities.
• Participants:
• Author of work product and peers of author
• Author of any predecessor work product
• People who will do work based on the item being
inspected
• People who are responsible for work products
that interface with the items being inspected.

35. Inspection Roles
• Author
• Moderator
• Reader
• Recorder

36. Defects Checklists
• They draw attention of inspectors on the typical
kind of errors that may be in the inspected
product.
• Defect checklist for use case documents
• Defect checklist for SRS

37. Entry Criteria
• The entry criteria set some clear
expectations for authors to follow while
preparing for an inspection.
• Following are some suggested entry criteria
for requirement document:
• Document conform to standard template
• Document has been spell-checked
• Layout errors are removed
• Predecessor or reference documents are
attached
• Line numbers are printed
• All open issues are marked as TBD

38. Exit Criteria
• Inspection process should define the exit
criteria that must be satisfied before the
moderator declares the inspection complete.
• All issues raised during the inspection have
been addressed.
• Any changes made in the document and
related work products were made correctly
• The revised document has been spell
checked
• All TBDs have been resolved

39. Tools for Inspections
• ASSIST
• Scrutiny
• ICICLE
• CSI
• WiP
• ReviewPro
• CheckMate

40. Requirement Review/Inspection Challenges
• Large requirement documents
• Large inspection teams
• Geographical separation of inspectors

41. Prototyping
• Prototypes for requirements validation demonstrate the
requirements and help stakeholders discover problems
• Validation prototypes should be complete, reasonably
efficient and robust. It should be possible to use them in
the same way as the required system
• User documentation and training should be provided

42. Prototyping for Validation
Choose
prototype
testers
Develop
test
scenarios
Execute
scenarios
Document
problems
Document and extend prototype system

43. Prototyping Activities
• Choose prototype testers
• The best testers are users who are fairly experienced and
who are open-minded about the use of new systems. End-
users who do different jobs should be involved so that
different areas of system functionality will be covered
• Develop test scenarios
• Careful planning is required to draw up a set of test
scenarios which provide broad coverage of the
requirements. End-users shouldn’t just play around with
the system as this may never exercise critical system
features

44. Prototyping Activities
• Execute scenarios
• The users of the system work, usually on their own, to
try the system by executing the planned scenarios
• Document problems
• Its usually best to define some kind of electronic or
paper problem report form which users fill in when they
encounter a problem

45. User Manual Development
• Writing a user manual from the requirements forces
a detailed requirements analysis and thus can reveal
problems with the document
• Information in the user manual
• Description of the functionality and how it is implemented
• Which parts of the system have not been implemented
• How to get out of trouble
• How to install and get started with the system

46. System Models
• For some projects, system models may be developed
based on the agreed set of requirements
• These models may be data-flow models of the
system’s functionality, object models, event models,
entity-relation models, process models, simulation
models etc
• Validation of system models is an essential part of the
validation process
• Some checking is possible with automated tools

47. Testing Requirements
• Research has shown that at least 50% of the
total software cost is comprised of testing
activities
• Test cases that are based on functional
requirements or derived from user requirements
help make the expected system behaviors
tangible to the project participants
• Each requirement should have a test case
– How to assess whether the requirement was
successfully implemented
• Typically a set of (future) functions in the
code will be tested by a test cases

48. Test Case Example
• The title "Registration Page" shall be left aligned at the top of the
page.
• The title "Registration Page" is left aligned at the
top of the page.
• The words "Registration Page" shall be spelled correctly.
• The words "Registration Page" are spelled
correctly.
• The words "Registration Page" shall be in 26 point type.
• The words "Registration Page" are in 26 point type
• The words "Registration Page" shall be in sans serif type
• The words "Registration Page" are in sans serif
type