SWE TEST 2 Chapter 6 A
REQUIREMENT ENGINEERING Definition
Requirements engineering is a set of activities related to the development and agreement of the final
set of requirement specifications
REQUIREMENT ENGINEERING 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. 4
REQUIREMENT ENGINEERING Preparation/Plan
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.
The plan for Requirement Engineering should include the following:
▪ Process (for requirements engineering) to be used
▪ Resources needed
▪ Schedule for completing the requirements activities
EQUIREMENT ENGINEERING
Challenges
Plan
Review
Management must also be involved
Analyst
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.
REQUIREMENT ENGINEERING
Importance (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
REQUIREMENT ENGINEERING
Importance (Cont.)
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.
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
Managing requirements and user involvement is emerging as a key task
in software development, regardless of
the software development process model.
Requirements engineering process is an iterative process that involves several steps which includes the
following:
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
ACTIVITIES/PROCESS
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.
Many software engineers start their careers in coding, designing, or testing a software system.
Only a few of them become requirements analysts. It is also essential that the analyst possesses both
communication skills and industry domain knowledge because each industry often has its own unique terminology.13
Requirement Elicitation (Cont.)The actual elicitation may be conducted in several modes:
1. Verbal
2. Written (preformatted form)
3. Online form
Requirement Elicitation (Cont.)
Requirement Elicitation Types:
There are two levels of requirements elicitation
High level and Low level(Detailed
Requirement Elicitation (Cont.)
Requirement Elicitation Types
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 High-Level Requirements
➢ Opportunity/needs
state what high-level problems the software suppliers have been brought in to address.
This is usually a business-oriented problem rather than a purely technical problem.
Requirement Elicitation (Cont.) - Eliciting High-Level Requirements Justification
in order to justify the solution and the cost, there must be some type of business payback.
Requirement Elicitation (Cont.) - Eliciting High-Level Requirements Scope
The areas for major requirements.
Requirement Elicitation (Cont.) - Eliciting High-Level Requirements Major constraint
like budget, schedule etc
Requirement Elicitation (Cont.) - Eliciting High-Level Requirements Major functionality
the major functionality the new software will be delivering
Requirement Elicitation (Cont.) - Eliciting High-Level Requirements Success factor
goes back to the opportunity and needs that were stated earlier. The software project, upon
completion, must resolve the problems stated in the opportunity and needs.
Requirement Elicitation (Cont.) - Eliciting High-Level Requirements User characteristics
Oftentimes, the executives and paying customers are not necessarily the day-today
users of the system. The success of the system depends heavily on how well these users are trained.
Requirement Elicitation (Cont.) - Eliciting Detailed Requirements (low level)
Once the high-level requirements are gathered, the detailed requirements
must be elicited
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
Requirement Elicitation (Cont.) - Eliciting Detailed Requirements
• Individual functionality
It is the natural starting point of requirements elicitation. The requirements analyst is
asking the users and customers what their problems are in terms of what functions need to be performed.
Requirement Elicitation (Cont.) - Eliciting Detailed Requirements Business flow
How the users perform their tasks to achieve the individual functionality.
Requirement Elicitation (Cont.) - Eliciting Detailed Requirements Data formats & information needs
At the minimum, there must be some discussion of the
application’s input and output data. What is the information that needs to be entered into the system and for
what purpose? If the entered data follow some business process flow, then that flow should also be described. If
there are data that serve as input for some processing, those must also be described.
Requirement Elicitation (Cont.) - Eliciting Detailed Requirements User interfaces
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.
Requirement Elicitation (Cont.) - Eliciting Detailed Requirements
• Systems with other interfaces
Besides interfaces with users, there are other interfaces such as those with an
existing application or to a network system. These interfaces must be clearly identified. In many situations, the existing
system interface already has many clients tied to it. In such cases, the requirement statements should not only describe
the interface but also indicate the likelihood of future changes. The most often forgotten portion of the interface is the
description of errors and error messages along with the respective recovery and retry methodologies
Requirement Elicitation (Cont.) - Eliciting Detailed Requirements Reliability, performance, security, and availability constraints
n large transaction-oriented applications, it is
imperative that a performance requirement on transaction rate be specified. In life-threatening applications, the reliability
and the availability parameters must be defined in the requirement statements. Availability addresses the system being
up, and reliability addresses the issue of it functioning properly without defect and according to specification. In large
financial applications or communications applications, the protection of the data and the protection of the transmission of
the data are of paramount significance. For these applications, the requirement statements must address the issue of
security.
REQUIREMENTS ENGINEERING
ACTIVITIES/PROCESS
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
20
REQUIREMENTS ENGINEERING
ACTIVITIES/PROCESS
2. Requirements Analysis - Clustering the requirements
Categories mentioned in the detailed requirement are not always mutually exclusive. At times there may be some
overlap. For example, under the category of constraints, there may be a requirement addressing reliability in the
form of backup recovery speed. In the individual functionality group, there may be a requirement describing the
need for backup recovery function. During the analysis time, an overlap must be clarified so that there is no
duplication. 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)
REQUIREMENTS ENGINEERING
ACTIVITIES/PROCESS
2. Requirements Analysis - Clustering the requirement 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)
REQUIREMENTS ENGINEERING
ACTIVITIES/PROCESS
2. Requirements Analysis - Clustering the requirements
Clustering by Viewpoint-Oriented Requirements Definition (Technique 3)
iew 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.
ACTIVITIES/PROCESS
2. Requirements Analysis - Clustering the requirements
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
business flow.
ACTIVITIES/PROCESS
2. Requirements Analysis - Clustering the requirements
Clustering with Object Oriented User Cases (Technique 2)
bject-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. 23
VORD methodology is divided into four steps
. 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.