Professional Documents
Culture Documents
Engineering
Requirement Engineering Process
Requirement Engineering (RE) is the process that
requires all of the activities required to create and
maintain a system requirements document.
RE provides the appropriate mechanism for
understanding ;
1. What customer needs
2. Analyzing need
3. Assessing feasibility
4. Negotiating a reasonable solution
5. Specifying the solution unambiguously
6. Validating the specification
7. Managing requirements as they are transformed into an
operational system.
Requirement Engineering Process
RE process can be described in five distinct steps
Requirement Elicitation
Requirement analysis and negotiation
Requirement Specification
System Modeling
Requirement Validation
Requirement Management
The Requirements Engineering Process
Feasibility Requirements
study elicitation and
analysis
Requir ements
specification
Feasibility Requirements
report validation
System
models
User and system
requirements
Requirements
document
Requirement Elicitation
Ian Sommerville
Requirement Engineering
CUSTOMER
USER DEVELOPER
Requirements
How Programs Are Usually
Written …
Lack of resources
Unrealistic expectations
Changing requirements
Lack of planning
Functional Requirements
The functional requirements define the fundamental actions
that the software must perform.
The actions describes accepting inputs, processing, and
generating the outputs.
Behavioral or Non Functional Requirements
The behavioral requirements define the actions taken when
the software responds to internal and external stimulus. This
includes describing what event causes an activity to start up
and the event that causes it to stop.
Requirements Types
Performance Requirements
The performance requirements specify the numeric
requirements that are placed of the software as well as on
the human interaction with the software.
Examples of performance requirements may include:
Number of data transactions with in a certain time frame
programming language.
Environment Restrictions. Example: Software size and resource
utilization.
Data Restrictions. Example: Maximum number of files and size of
files.
Participants
Buyer
The buyers are the individuals that are responsible for
the acceptance of the software.
A buyer can be an internal department of an
organization, external customer, or the general public.
Whatever the origins, the buyers are responsible for
contracting or paying for the software system.
End-User
The end-users are the individuals who ultimately uses
the system to perform some predefined set of tasks.
Ultimately, the end-users will be the individuals who
install, operate, and use the software.
Participants
Application Experts
The application experts are the individuals who provide domain
knowledge and supplies a more detailed understanding of the
problem.
Software Engineers
The software engineers are the individuals who provide expertise
on software design, prototype development, and technical
feasibility. The software engineers works closely with the end-
users, buyers, and application experts.
Requirements Engineer
The Requirements Engineers are the individuals who are
responsible for the identification and documentation of the
requirements. These individuals are also the mediate between
the buyers, end-users, application experts, and the software
engineers.
Participants Activities
Context Analysis
Determines the underlying need of why the software is to be
created.
The technical, operational, and economic boundaries are
determined and the scope of the software system is documented.
Requirements Elicitation
The requirements elicitation activity creates the required
knowledge structure by gathering requirement related information.
Techniques for requirement Elicitations are :
Joint Application Development
Questionnaires
Interviews
Observation of operational environments
Participants Activities
Requirements Assessment
The requirements assessment activity performs a risk
assessment on the documented software requirements.
The goal of this activity is to achieve an acceptable level of
risk concerning the potential problems of:
Inconsistencies with the software requirements
Ambiguities
Incompleteness
Exploration of design Feasibility
The exploration of design feasibility activity is concerned with
assessing technical feasibility and
Making requirements tradeoffs may require a demonstration
that a feasible software design does exist.
Participants Activities
All requirements that are identified during the
Requirement Engineering activities are
documented in the Software Requirements
Specification (SRS). The goal of the SRS is to
describe all externally observed behaviors
and characteristics expected of the software
system.
Software Requirements Document
References
IEEE Standard
General description
Product Perspective
Product functions
User characteristics
General constraints
Feasibility Requirements
study elicitation and
analysis
Requir ements
specification
Feasibility Requirements
report validation
System
models
User and system
requirements
Requirements
document
Requirement Engineering Process