Requirement Management SE

1. Introduction to Requirement
Management

2. Learning Objectives
By the end of the lecture you should be able to:
 Explain what is software requirement analysis
 Describe how to carry out requirement analysis
 Explain different mechanisms of documenting
requirement analysis
 Decision Table
 Decision Tree
 Structured English
 Use Case Diagram
 Use Case Template
2

3. What Are the Real Problems?
the customer has only a vague idea of what is
required
the developer is willing to proceed with the
"vague idea" on the assumption that "we'll fill in
the details as we go"
the customer keeps changing requirements
the developer is "ratcheted" by these changes,
making errors in specifications and development
and so it goes ...

4. Software Requirements Analysis
 identify the “customer” and work
together to negotiate “product-level”
requirements
 build an analysis model
 focus on data
 define function
 represent behavior
 prototype areas of uncertainty
 develop a specification that will guide
design
 conduct formal technical reviews

5. What is a requirement
 It is about WHAT not HOW
 Nothing can be said obvious
 Requirements are the descriptions of the services
provided by a system and its operational
constraints
 It may range from a high level abstract statement
to a detailed mathematical specification
 It may be as complex as a 500 pages of
description
 It may serve as the basis for a bid for a contract
or the basis for the contract itself

6. Requirements engineering?
 It is the process of discovering, analyzing,
documenting and validating the requirements of the
system
 Each software development process goes through the
phase of requirements engineering
 Business Requirement Document will assist
throughout the project lifecycle to keep the
deliverable in line with the business and customer
needs.

7. Key points
 The software requirements document is an agreed
statement of the system requirements. It should be
organized so that both system customers and software
developers can use it.
 The requirements engineering process is an iterative
process including requirements elicitation, specification
and validation.
 Requirements elicitation and analysis is an iterative
process that can be represented as a spiral of activities
– requirements discovery, requirements classification
and organization, requirements negotiation and
requirements documentation.

8. A spiral view of the requirements engineering
process

9. Requirements Elicitation and Analysis
 Sometimes called requirements elicitation or
requirements discovery.
 Involves technical staff working with customers
to find out about the application domain, the
services that the system should provide and the
system’s operational constraints.
 May involve end-users, managers, engineers
involved in maintenance, domain experts, trade
unions, etc. These are called stakeholders.

10. Problems in Requirements Analysis
 Stakeholders don’t know what they really want.
 Stakeholders express requirements in their own terms.
 Different stakeholders may have conflicting requirements.
 Organisational and political factors may influence the
system requirements.
 The requirements change during the analysis process.
New stakeholders may emerge and the business
environment may change.

11. Requirements elicitation and
analysis process
11
•Requirements discovery,
•Requirements
classification and
organization,
•Requirements
prioritization and
negotiation,
•Requirements
specification.

12. Process activities
 Requirements discovery
 Interacting with stakeholders to discover their
requirements. Domain requirements are also
discovered at this stage.
 Requirements classification and organisation
 Groups related requirements and organises them
into coherent clusters.
 Prioritisation and negotiation
 Prioritising requirements and resolving
requirements conflicts.
 Requirements specification
 Requirements are documented and input into the
next round of the spiral.

13. Types of Requirements
 Functional requirements
 Services the system should provide
 What the system should do or not in reaction to
particular situations
 Non-functional requirements
 Constraints on the services or functions offered by
the system
 Examples: Timing constraints, constraints on the
development process, standards etc

14. Writing system requirements
 Natural language (informal requirements)
 Criticized by academics
 But widely practiced: everybody can read them, finding a better
notation is hard
 Structured natural language
 Forms/templates are used to bring some rigor to natural language
presentations
 Graphical notations
 Using boxes, arrows… but they mean different things to different
people
 Formal specification
 Based on logic, state machines…
 Hard to understand for many people

15. Requirements Gathering
Facilitated Application Specification Techniques
Software
Engineering
Group
Customer
Group

16. Techniques for gathering
requirement
 Brainstorming
 Document Analysis/ Gap Analysis
 Focus Group
 Interface Analysis
 Interview
 Observation
 Prototyping
 Requirements Workshop
 JAD Session (Joint Application Development)
 Survey/ Questionnaire

17. FAST Guidelines
 participants must attend entire meeting
 all participants are equal
 preparation is as important as meeting
 all pre-meeting documents are to be viewed
as “proposed”
 off-site meeting location is preferred
 set an agenda and maintain it
 don’t get mired in technical detail

18. Key skill requirement for
information gathering
 Good Communication Skills
 People Skills
 Strong Analytical Ability
 Healthy Relationship Building
 Domain Knowledge
 Technical Proficiency
 Reading and Listening Skills

29. Structured English

32. Practice Sum

33. Use-Cases
 A collection of scenarios that describe the thread of
usage of a system
 Each scenario is described from the point-of-view of an
“actor”—a person or device that interacts with the
software in some way
 Each scenario answers the following questions:
 What are the main tasks of functions performed by the actor?
 What system information will the actor acquire, produce or
change?
 Will the actor inform the system about environmental changes?
 What information does the actor require of the system?
 Does the actor wish to be informed about unexpected changes