1. Requirements Engineering
Chapter 7
Requirements Engineering
Elements of software requirement gathering

2. What is Software Requirement?
“A software requirement is a description of the principle features of a software product, its information flow, its behavior, its attributes. In sum, a software requirement provides a blueprint for the development of a software product. The degree of understandability, accuracy, and rigor of the description provided by a software requirement document tends to be directly proportional to the degree of quality of the derived product.”
Source: Software Engineering: An Engineering Approach, by James Peters and Witold Predrycz, Wiley, 2000, Page 118.

3. Requirements Engineering
Goal: Better understanding of the problem at hand and business impact of the system.
How is it done? Through a process that facilitates a set of defined tasks.
Why do it? To establish a solid foundation for system design and construction.
It is not the solution, but an approach to facilitate the development of a effective solution.

4. What is Software Requirements Analysis? - 1
Software requirements analysis is process of understanding customer requirements of the software system to be built, and building analysis model of the system (data, functions, behaviour/control flow, interfaces).
The analysis model serves as
- basis for creating specifications and software design
- means for assessing the quality of the system to be built
This process requires active participation of the customer, and it is crucial step in the development process. The analyst may play different roles - interrogator, advisor, problem solver, and negotiator.

5. What is Software Requirements Analysis? - 2
The outcome of the process:
- Software Requirements Specifications (SRS). The SRS should be clear, complete, and consistent with customer needs.
- Quality Assurance Plane - set of activities that the project team can follow to ensure software quality throughout the product life cycle (portability, reliability, efficiency, V&V criteria, cost, acceptance criteria, etc…)

6. System vs. Software Requirements
System requirements analysis, in part, focus on how the software element interacts with other elements of the system (constraints and limitations).
Software requirements analysis focus on the data, functional, and behavioural modeling of the software itself (OOA focuses on classes, relations, and object behaviour modeling).
For software requirements analysis, try to fully answer the following:
- What are the inputs and outputs?
- What functions should be defined?
- What behaviors (control activities) should be exhibited?
- What interfaces are needed?

7. Why Do Requirements Analysis?
- Identify the customer and work together to negotiate product-level requirements
- Build an analysis model (focus on data, define functions, represent behaviour)
- Prototype areas of uncertainty in the system
- Develop a specification to guide the design and development
- Conduct formal technical reviews to ensure software quality

8. The Analysis Process build a prototype requirements develop
the problem
requirements
elicitation
build a
prototype
create
analysis
models
develop
Specification
Review

9. Problem Analysis Problem Analysis Operations Products Environment
Functions
- People (operators and users)
- Devices
Other items affected by the system
business value
- Inputs
- Outputs
- Items produced for the system
- People functions
- Device functions
- Other functions needed to produce services and items
- Methods used
- operations used to produced items
- When operations occur

10. Real Problems…
- the customer has only a vague idea of what is required.
- the software engineer (analyst) 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 software engineer (analyst) is affected by these changes, making errors in the specifications. ?
and so it goes ...

11. Requirements Engineering Tasks - 1
Inception: Starting the project… where to star?
Ask a set of questions that establish
- basic understanding of the problem
- the people who want a solution
- the nature of the solution that is desired, and
- the effectiveness of initial communication and
collaboration between the customer and the developer
Elicitation: Elicit requirements from all stakeholders
Elaboration: Modeling and refinement (chapter 8) - create analysis model that identifies data, function and behavioral requirements. (in OOA, analysis classes, their services, their relationships).
Negotiation: Agree on a deliverable system that is realistic for developers and customers.

12. Requirement Engineering Tasks - 2
Specification: Can be any one (or more) of the following:
A written document
A set of models
A formal mathematical
A collection of user scenarios (use-cases)
A prototype
Validation: A review mechanism that looks for
errors in content or interpretation
areas where clarification may be required
missing information
inconsistencies (a major problem with large systems)
conflicting or unrealistic (unachievable) requirements
Conformity issues (with standards set for the product, process, project)

13. Requirement Engineering Tasks - 3
Requirements management: A process to identify, control, and track changes to requirements (similar to SCM)
Traceability tables facilitate requirements management
feature (of system) traceability table (see figure 7.1, page 148)
source (of requirements) traceability table
dependency (among requirements) traceability table
subsystem traceability table (categorization of requirements)
interface traceability table

14. Inception Identify stakeholders
“who else do you think I should talk to?”
Recognize multiple points of view
Work toward collaboration (productive meetings)
The first questions to ask:
Who is behind the request for this work?
Who will use the solution?
What will be the economic benefit of a successful solution?
Is there another source for the solution that you need? …
(see page 152)

15. Elicitation - 1 Initial interview:
- break the ice and establish communications channels
- scripted (context-free) questions may be used
understand customer goals and scope the problem
identify stakeholders interested in the system
Sample questions:
- What do you expect of the new system?
- How will the system help your organization?
- Who will be using the system?
- Will the system interact with other systems?
- etc…

16. Elicitation - 2
There is not one way for gathering requirements from the client…
The meeting format determines its effectiveness and outcomes.
It is important to listen, but that is not enough! In addition to meeting notes, recording the meetings may be required.
One approach is called Facilitated Application Specification Techniques (FAST) . It is a team-oriented approach to promote constructive and effective communications.

17. FAST Approach 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
focus on requirements and don’t get mired in technical details
Benefits: many points of view, instantaneous discussion and
refinement, concrete step toward developing specs.

18. Collaborative Approach
Guidelines:
Meetings are conducted and attended by both software engineers and customers
Rules for preparation and participation are established
An agenda is suggested
A "facilitator" (can be a customer, a developer, or an outsider) controls the meeting
A "definition mechanism" (can be work sheets, flip charts, or wall stickers or an electronic bulletin board, chat room or virtual forum) is used
The goal is to identify the problem, propose elements of the solution, negotiate different approaches, and specify a preliminary set of solution requirements

19. Quality Function Deployment (QFD) - 1
Another approach for requirements gathering. Its purpose is to maximize customer satisfaction while developing software requirements that are valuable to the customer. It identifies three types of requirements:
- Normal requirements: what the customer explicitly states
and wants in the system.
- Expected requirements: what the customer wants but did
not explicitly state assuming we know such requirements.
- Exciting requirements: additional features we can offer.

20. Quality Function Deployment (QFD) - 2
QFD meeting aspects (deliverables/outcomes):
- Function deployment: determines the “value” (as perceived
by the customer) of each function required of the system.
- Information deployment: identifies data objects and control
events of the system (based on required functions).
- Task deployment: illustrate system behavior in the target
environment.
Value analysis activity determines the priority of system requirements identified in the above deliverables.
Check QFD Institute at

21. Elicitation Work Products
a statement of need and feasibility (or statement of work).
a bounded statement of scope for the system or product.
a list of customers, users, and other stakeholders who participated in requirements elicitation.
a description of the system’s technical environment.
a list of requirements (preferably organized by function) and the domain constraints that apply to each.
a set of usage scenarios that provide insight into the use of the system or product under different operating conditions.
any prototypes developed to better define requirements.

22. Use-Cases - 1
Another approach to requirement gathering is Use-cases. Use case are scenarios of system usage by different actors (classes of users and devices).
e.g., student, faculty, and registrar are actors for
student registration system.
- Uses-cases are used to:
- obtain requirements from the customer
- effectively express requirements to the customer
Annotated diagrams are common way to present use-cases.

23. Use-Cases - 2 Some of the questions a use-case should answer:
- What are the main functions performed by the actor?
- What information will the actor acquire, produce or change?
- What information does the actor desire of the system?
- others…
Check the article “Structuring Use Cases with Goals” at:
Structuring+use+cases+
with+goals
See example page 161.
Retrieve a file use-case
1. User clicks file menus
2. System displays options new and open
3. User clicks option open
4. System displays open file window
5. User enters/selects file name
6. User clicks open button
7. System retrieves and opens the file

24. Analysis Principles - 1
Analysis methods may vary, but they share common principles:
1. Information Domain Analysis and Data modeling:
- define data (and control) items/objects
- describe data attributes
- establish data relationships and data structures
e.g., student transcript (data object) with different attributes.
2. Function modeling: (iterative process)
- identify functions that transform data objects
- indicate how data flow through the system
- represent producers and consumers of data objects

25. Analysis Principles - 2 3. Behaviour modeling:
- indicate different states of the system
- specify events that cause the system to change state
4. Partitioning the model:
refine each sub-model to represent lower levels of abstraction
- refine data objects
- create a functional hierarchy
- represent behavior at different levels of details
5. The essence: focus on the problem (requirements) not the
implementation details (i.e., answer “what” questions).

26. From DoD SRS Standard DI-MCCR-80025A
SRS Structure
Table of Contents
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, acronyms, and
abbreviations
1.4 References
1.5 Overview
2. Overall description
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 Constraints
2.5 Assumptions and
dependencies
3. Specific requirements (next box) Requirement traceability
Appendices
Index
3. Specific requirements
3.1 Interface requirements
3.2 Functional requirements
3.3 Performance requirements
3.4 Design constraints
3.5 Software system attributes
3.6 Other requirements
For SRS details and other templates, check author’s site at
From DoD SRS Standard DI-MCCR-80025A

27. Building Analysis Model
Elements of the analysis model: (more in Chapter 8)
- Scenario-based elements
Functional: Processing narratives for software functions
Use-case: Descriptions of the interaction between an “actor” and the system
- Class-based elements
Implied by scenarios
- Behavioral elements (depict system behavior)
State transition diagram
- Flow-oriented elements
Data flow diagram
SRS Templates and “SRS Components” document will be posted on
the Project Page.

28. Negotiate Requirements
Identify the key stakeholders
These are the people who will be involved in the negotiation
Determine each of the stakeholders “win conditions”
Win conditions are not always obvious
Negotiate
Work toward a set of requirements that lead to “win-win” deal

29. Validate Requirements - 1
Is each requirement consistent with the overall objective for the system/product?
Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage?
Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system?
Is each requirement bounded and unambiguous?
Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement?
Do any requirement conflict with other requirements?

30. Validate Requirements - 2
Is each requirement achievable in the technical environment that will house the system or product?
Is each requirement testable, once implemented?
Does the requirements model properly reflect the information, function and behavior of the system to be built.
Has the requirements model been “partitioned” in a way that exposes progressively more detailed information about the system.
Have requirements patterns been used to simplify the requirements model. Have all patterns been properly validated? Are all patterns consistent with customer requirements?

31. Deployment Practices
Deployment involves system delivery, end-user support, and feedback from end-users.
Principles:
Manage customer expectations for each increment
A complete delivery package should be assembled and tested
A support group should be established before delivery
Instructional materials must be provided to end-users
Buggy software should be fixed first, delivered later
Encourage and collect customer feedback on the system

32. Suggested Problems
Consider working the following problems from the end of chapter 7, page 173, for practice purpose:
7.1, 7.2, 7.3, 7.4, 7.11, 7.13, 7.16, 7.17
No submission is required. Think about these problems and work them for yourself!

33. Last Slide
End of Chapter 7