Course: Software Development Processes - Assignment 2
Chapter 6: Requirements Engineering
1
Preparation for Requirements Engineering
1. Prior to actually performing the requirements engineering activities, it is important to plan for the resources, methodology, and time needed to perform this crucial step in software engineering.
2. Some organizations even perform requirements engineering as a separate, stand-alone activity and price it separately, with the option of folding the cost into the whole project if they get the call to complete the software project.
2
Major Requirements Engineering Activities
Elicitation
Documentation and definitions
Prototyping
Analysis
Specification(s)
Review and validations
Gain agreement and acceptance
Note: This list does not address “inventing” new requirements.
3
Requirements Engineering Activities
4
Why Is This Set of Activities Important and Why Should Requirements Be Documented? (Remember Chaos Report?)
Clear requirements are needed for design and implementation activities.
Requirements documentation is needed to create test cases and test scenarios—especially for large systems where the test team is a separate group of people from the developers.
Requirements document is needed to control potential scope-creep.
Requirements document is needed to create user training material, marketing material, and documents for support and maintenance.
Requirements document provides a way to segment a large project, prioritize releases, and simplify project management.
Think about agile processes where this crucial step may sometimes be
“compromised” by the novice software engineers.
5
Requirements Elicitation
Requirements:
May be given to the software engineers.
Initial product/system requirements
For second and/or third follow-on release of a “planned” sequence of software product where a preliminary set of requirements are already established
Requirements provided as part of a request for price quotation for a software development project
Have to be established by software engineers.
Users sometimes have an understanding of only the requirements related to their specific job tasks.
The business rationale and goals are not always clear to individual user and needs to be established for prioritization reason.
There may be contradicting and incomplete requirements stated by the users and customers.
6
High-Level Requirements Elicitation
Need to seek out the business and management perceptions and goals for the software project.
Business opportunity and business needs
Justification for the project
Scope
Major constraints
Major functionality
Success factor
User characteristics
Software engineers who have to interact with business management
and handle requirements are sometimes called business analysts.
7
6 Dimensions of Detailed Requirements Elicitation
8
Requirements Analysis
Requirements “analysis” is composed of:
Categorizing the requirements (by some criteria)
Prioritizing the requirements
Also “start to look” for consistency and completeness (see VORD Slide)
9
Requirements Classification/Categorization
Most high level:
Functional
Non-functional
Other more detailed grouping also exists.
Six dimensions of requirements
10
Requirements Categorization
By detailed six requirements areas:
Individual functionality
Business flow (usage “scenarios”)
Data and information needs
User interfaces
Other interfaces to external systems/platforms
Various constraints (non-functional)
Performance
Security
Reliability
Etc.
11
Requirements “Analysis/Categorization” of Multiple Views
View-oriented requirements definition (VORD) is based on the concept that requirements are viewed differently by different people.
Identify stakeholders and their viewpoints of the requirements.
Categorize the viewpoints of requirements and eliminate any duplication (look for consistency and completeness).
Refine the identified viewpoints of requirements.
Map the viewpoints of requirements to the system and the services that the system must provide.
12
Requirements Prioritization
Most of the time we have some limitations in developing software:
Time
Resources
Technical capabilities (existing)
We need to prioritize the requirements to satisfy these limitations.
13
Requirements Priorities
Some criteria for prioritization:
Current user/customer demands or needs
Competition and current market condition
Anticipated future and new customer needs
Sales advantages
Existing critical problems in current product
These are often subjective and requirements should be prioritized with the help of many of the stakeholders (different viewpoints).
14
A Simple Requirements Prioritization List “Sample”
* Priority may be 1, 2, 3, or 4, with 1 being the highest.
15
Requirements Comparison and Prioritization
Requirements prioritization is an activity of comparing requirements and placing them in some order relative to each other.
Is it always performed with just experience and gut feel?
and/or
Done with a little more rigor?
Sort by priority groups (e.g., previous 2 charts) where the priority groups are based on some prioritization criteria list (e.g., current user needs has the highest priority).
Pair-wise comparison: normalize and compute relative value using the Analytical Hierarchical Process (AHP) – see pages 159–161 of textbook (you are responsible for reading this).
16
Analytical Hierarchical Process (AHP) Example
| Req 1 | Req 2 | Req 3 | |
| Req 1 | 1 | 2 | 3 |
| Req 2 | 1/2 | 1 | 2 |
| Req 3 | 1/3 | 1/2 | 1 |
| Req 1 | Req 2 | Req 3 | |
| Req 1 | .55 | .57 | .5 |
| Req 2 | .27 | .29 | .33 |
| Req 3 | .18 | .14 | .17 |
1.83
3.5
6.0
.49
.89
1.62
Requirements Prioritization
Req 1 = 1.62 / 3 = 54%
Req 2 = .89 / 3 = 30%
Req 3 = .49 / 3 = 16%
17
Requirements Definition/Prototyping/Review
Once the requirements are solicited, analyzed, and prioritized, more details may/must be spelled out. Three major activities that may be intertwined must be performed:
Requirements definition
Requirements prototyping
Requirements reviewing
18
Requirements Definitions/Documentation
Requirements definitions may be written in different forms:
Simple input/process/output (I-P-U) descriptions in English
Dataflow diagrams (DFD)
Entity relations diagram (ERD)
Use case diagram from Unified Modeling Language (UML)
Once the requirements are defined in detail using any of the above forms, they still need to be reviewed (see Chapter 10 of your textbook) by the users/customers and other stakeholders.
Formal
review
by others
19
Requirements Definition Using English and Input-Process-Output Diagram Form
English I-P-O: functionality, business, and data flow
20
Syntax of Data Flow Diagram (DFD)
21
Requirements Definition Using DFD
Captures functionality, business flow, data.
22
4
Requirements Definition Using Entity Relation Diagram (ERD)
Captures relations among data.
23
Requirements Definition Specifying Entity and Attributes
Captures relations among data.
24
Requirements Analysis & Definition Methodology Using UML
Using OO Use Case Methodology and Notation, which identifies:
Basic/main functionalities
Pre-conditions of functionality
Flow of events or scenarios
Post-conditions for the functionality
Error conditions and alternative flows
Using OO Use Case Diagram, which identifies:
Actors (or all external interfaces with the system, including the users)
Related “use cases” (major functionalities)
Boundary conditions
Use cases may be further refined during design.
25
Requirements Definition Using Use Case Diagram (for major functionalities)
26
Requirements Definition Using Use Case Description
Use case diagrams are mostly for functionalities and are not detailed enough—so we need to use “English” text for further descriptions of the requirements:
Functional details
Pre-conditions
Post-conditions
Non-functional characteristics about the functionalities
“Alternative paths” (e.g., error processing)
UI sample (e.g., “looks”)
Etc.
27
Requirements Traceability
Capability to trace a requirement is needed to ensure that the product has fully implemented the requirements (while not part of requirements process activities – it needs to be started early).
We need to trace requirements:
Requirements from source (people and documents)
Requirements to later steps (design, implementation, test, and release)
We also need to link requirements to other “prerequisite” requirements.
28
Partially Filled Traceability Table
| Requirement | Design | Code | Test | Other Related Requirements |
| 1 | compon. X | Module 3 | Test Case 32 | 2, 3 |
| 2 | compon. w | Module 5 | Test Case 16 | 1 |
| 3 | compon. X | Module 2 | Test Case 27 | 1 |
| 4 | ||||
| 5 | ||||
| 6 | ||||
| 7 |
29
Requirements Prototyping
Requirements prototyping mostly addresses the user interface (UI) part of the requirement in terms of:
Visual looks (size, shape, position, color)
Flow (control and logical flow; depth of flow)
The prototyping may be performed in one of the two modes:
Low fidelity: using paper/cardboard to represent screens and human to move the boards
High fidelity: using automated tools such as Visual Basic to code the screens and direct the logical flow of these screens
30
Requirements Specification
Once the requirements are defined, prototyped, and reviewed, they must be placed into a Requirements Specification document.
IEEE /EIA Standard 12207.1-1997 may be purchased from IEEE. It outlines the guideline for three major sections of a requirements specification document.
Introduction
High-level description
Detailed descriptions
Details of each functionality (input-output-process)
Interfaces, including user interfaces and network interfaces
Performance requirements (response time, throughput, etc.)
Design constraints, standards, etc.
Additional attributes such as security, reliability, etc.
Any additional unique requirements
31
Finally — Requirements “Sign-Off”
Having a requirements specification agreed to and signed off on is important.
Serves as a milestone marker and formally exits a phase of software engineering.
Serves as baseline from which any future changes can be monitored and controlled.
Remember “agile”—which wants less “legalese” like sign-off
—obviously, I disagree when it comes to large/expensive projects!
32