Intro SWE Chapter 6 (A) Part One
REQUIREMENT ENGINEERING
Process/Activity
1. Requirements Elicitation
2. Requirements Analysis
3. Requirements Definition
4. Requirements Prototyping
5. Requirements Review and validation
6. Requirements Specification
7. Requirements Agreement and acceptance
Requirements engineering Definition
Requirements engineering is a set of activities related to the development and agreement of the final
set of requirement specifications.
Need
Requirements are the statements that describe what the software system should be but not how it is
to be constructed.
One of the top reasons for software project failures is incomplete requirement specifications,
At the same time, one of the important reasons for project success may be attributed to clear
requirements statements.
REQUIREMENT ENGINEERING
Preparation/Plan
Preparation/Plan
The plan for Requirement Engineering should include the following:
▪ Process (for requirements engineering) to be used
▪ Resources needed
▪ Schedule for completing the requirements activities
REQUIREMENT ENGINEERING
Challenges (Plan)
The plan itself may take several hours to several days or weeks to develop depending on the size and
complexity of the project.
REQUIREMENT ENGINEERING
Challenges (Review)
Once the plan is drawn, it must be reviewed and agreed on by all parties involved. This agreement and
commitment to the plan is extremely important because requirements are not just an imagination of the software
designer or developer. The users and customers must be involved because requirements represent their needs
and desires.
REQUIREMENT ENGINEERING
Challenges ( Management must also be involved)
because resources are required to perform the activities. There have been
situations where prototype development, reviews, and changes to the user-interface requirement alone have
taken such a significant portion of the software development resources and schedule that the project was
doomed for a later schedule crunch and cost overrun.
REQUIREMENT ENGINEERING
Challenges (Analyst)
Finding qualified requirements analysts may be a time-consuming effort, for a good requirements
analyst must possess multiple talents such as communication skills, special industry skills, and technical skills
Importance
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 easier
project management
Scope creep
Scope creep (sometimes known as “requirement creep” or even “feature creep”) refers to how a project’s
requirements tend to increase over a project lifecycle, e.g., what once started as a single deliverable becomes
five; or a product that began with three essential features, now must have ten; or midway through a project, the
customer's needs change, prompting a reassessment of the project requirements.
1. Requirement Elicitation
The Requirements analysts perform the elicitation and gathering of requirements from the users and customers.
Sources of gathering include stakeholders, existing systems, existing documents, competitors and similar
systems, company policies, laws and standards.
This is the process of gathering information about the needs and expectations of stakeholders for the software
system.
This step involves interviews, surveys, focus groups, and other techniques to gather information from
stakeholders.
Requirement Elicitation (Cont.)
The actual elicitation may be conducted in several modes:
1. Verbal
2. Written (preformatted form)
3. Online form
Requirement Elicitation Types:
There are two levels of requirements elicitation - High level and Low level(Detailed).
Eliciting High-Level Requirements
At the high level, the requirements analyst must probe and understand the business rationale and justification for
the software or the software project. These high-level business-related requirements are essential to the overall
success of the software project. Even when a few detailed requirements may be misplaced, the project is often
deemed a success if the high-level business goals are met.
Requirement Elicitation (Cont.) - Eliciting Detailed Requirements (low level)
Once the high-level requirements are gathered, the detailed requirements must be elicited. During this activity, some
of the more technically savvy requirements analysts should be brought in. Often during these requirements
gathering engagements, both the requirements analyst and the users may enter into imaginative and technical
conversations
Individual functionality
what functions need to be performed.
Business flow
How the users perform their tasks to achieve the individual functionality
Data formats & information needs
input and output data. What is the information that needs to be entered into the system and for what purpose?
User interface
Though most prefer graphical, different users have their unique preferences with what kind of
choices to use within the same as radio button or a drop-down window. The user-interface requirements,
both the look and the flow, are often captured by prototyping the interface.
2. Requirements Analysis
During the analysis step, the various requirements statements are checked for accuracy and conflict,
categorized, and prioritized. Even though there is an arrow from requirements analysis back to requirements
elicitation, there is usually very little opportunity to continue going back because of the scarce availability of the
users who provide the requirements information. The requirements that are elicited and collected are still just
an unorganized set of data. They must still be analyzed. The analysis of the requirements consists of two main
tasks:
❖ Categorizing or clustering the requirements (Based in some criteria)
❖ Prioritizing the requirements
Requirements Analysis - Clustering the requirements
Each requirement must be labeled so that it is uniquely identifiable and traceable.
Approaches for clustering are:
1. Business Flow
2. Object-Oriented Use Cases
3. Viewpoint-Oriented Requirements Definition (VORD)
Clustering by Business Flow (Technique 1)
• When analyzing the requirements, it is best to start with
the business flow category.
• Pick a business flow first.
• Assign it the first number, such as BF-1
• Associate all the functionality requirements and number
them IF-1.x. The additional x may be used if there is more
than one functionality related to the workflow.
• This is followed bt the data requirements, user interfaces
& the other system interface.
• The numbering scheme of all categories is tied to
Requirements Categorization Scheme
business flow.
Requirements Analysis - Clustering the requirements
Clustering with Object Oriented User Cases (Technique 2)
Object-oriented (OO) use cases are used to describe the requirements of a system.
They are also used for the analysis of requirements and contribute to the design and testing of the system.
A use case is fundamentally a depiction of the following requirement information:
✓ Basic functionality
✓ Any precondition for the functionality (A precondition is the state of the system and its surroundings that is
required before the use case can be started).
✓ Flow of events, called a scenario, for the functionality
✓ Any postcondition for the functionality (A post-condition of a use case lists possible states that the system can
be in after the use case runs.)
✓ Any error condition and alternative flow.
Requirements Analysis - Clustering the requirements
Clustering by Viewpoint-Oriented Requirements Definition (Technique 3)
View Oriented Requirements Definition (VORD) is based on the concept that requirements are viewed differently by different
people. The customers who pay for the system often have a different perspective on requirements than those who interface
with the system on a daily basis. For a large, complex system that has many subcomponents, the different users will articulate
the requirements with varied emphasis and diverse specifics. Sometimes the same requirement is stated in such different
forms and context that they seem to be different requirements. Other times, the different requirements overlap so much that
they should be reorganized and combined in a totally different way.
VORD methodology is divided into four steps:
1. Identify the stakeholders and the viewpoints.
2. Structure and categorize the viewpoints, eliminating duplication, and placing common ones together.
3. Refine the identified viewpoints.
4. Map the viewpoints to the system and the services that the system is to provide.
Requirements Analysis - Prioritizing the requirements
Categorizing and clustering requirements is only a part of an analysis that enables us to identify
inconsistencies across groups of requirements and possible incompleteness in requirement
Requirements Analysis - Prioritizing the requirements
Categorizing and clustering requirements is only a part of an analysis that enables us to identify
inconsistencies across groups of requirements and possible incompleteness in requirements. An additional
problem is that many times all the identified requirements cannot be developed and delivered because of
constraints such as the following:
Limited resources
o Limited time
o Limited technical capabilities
We need to prioritize the requirements to satisfy these limitations.
Requirements Analysis - Prioritizing the requirements
We need to prioritize the requirements to satisfy these limitations.
As a part of the requirements analysis tasks, we need to prioritize the requirements so that the higher priority
ones are developed and released to the customers first.
Establishing the priority of the requirements may be based on many criteria,
▪ Current customer demands
▪ Competition and current market condition
▪ Future customer needs
▪ Immediate sales advantage
▪ Critical problems in the existing product
3. Requirements Definitions/Documentation
The analyzed requirements must be properly defined and documented. In large systems, this effort itself may
resemble a mini development project.
3. Requirements Definitions/Documentation
The analyzed requirements must be properly defined and documented. In large systems, this effort itself may
resemble a mini development project. Requirements definition involves formally spelling out the requirements. The
notation used is often English or English accompanied with other notations. Requirements definitions may be written
in different forms:
1. Simple Input/Process/Output
2. Dataflow diagrams (DFD)
3. Entity Relations diagram (ERD)
4. 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 by the
users/customers and other stakeholders.
4. Requirement Prototyping
If necessary, some of the requirements, especially the user-interface aspects, need to be prototyped. In large
systems, this effort itself may resemble a mini development project.
Requirements prototyping mostly address 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)
4. Requirement Prototyping
1. Low fidelity:
using paper/cardboard to represent screens and human to move the boards
4. Requirement Prototyping
2. High fidelity:
using automated tools such as Visual Basic to code the screens and direct the logical flow of
these screens
5. Requirements Review
Closely related to requirements analysis and user-interface prototyping is the review of requirements with the users and
customers. These reviews may be conducted informally and very frequently as proposed by the Agile methods or they
can be more formal in nature.
The users must commit their time and people during the requirements elicitation and review periods. These three
sub steps may iterate among themselves and also with the analysis step. The iterations must be properly managed, or
it will turn into a vicious cycle of schedule and resource consumption. It is important to realize that reviewing
requirements with users and customers is an essential part of the requirements analysis and prototyping.
Catching requirements errors early is of extreme significance in that a single requirement error often expands into
multiple design errors, each of which in turn may become a source of several programming errors. After reviews are
conducted, any modification and correction must be made to the requirements definitions. Sometimes a follow-up
review over the modifications and changes is necessary if the extent of corrections is very large.