SE Activity 5& 6

Software Engineering
Activity # 5 & 6
Software Requirement Engineering

• Software requirements
• Types of Requirements
• Requirement Engineering
• Requirement Engineering process
The objectives of this activity are:
• To introduce the concepts of user and system
requirements
• To describe functional and non-functional requirements
• To explain processes of requirement engineering
• To explain how software requirements may be organised
in a requirements document
BDU, SE-(Specification) 2
Introduction
• If you are required to develop a library information
software system, what will you do firstly?
– What functions that the system may have?
– What behaviors that the system may have?
– What performances that the system may have?
– What is the scope and boundary of the software?
– ...
Software requirements
• To understand customers’ requirements about the software
to be developed is extremely important.
• Requirement: A function, constraint or other property that the
system must provide to fill the needs of the system’s intended
user(s)
– It is the descriptions of the system services and constraints.
• Sample of requirements for Library system
– Function: borrow book, renew book, …
– Performance: the time of query book must be lower 1 second
– Constraints: software should be deployed and run under windows
OS
– Schedule: development period is 6 months
Cont’d…
• Customers are unable to express requirements explicitly
– Typically, they can not tell you what they want clearly.
• Stakeholders (Business and Technical groups) speak
different languages.
• Software requirements are often extremely complex and
large scale.
• The requirements that customers or end-users present are
often: incomplete, inaccurate, and inconsistent.
• That is why engineering requirements is needed
Requirement Engineering
• Engineering: implies that systematic and repeatable techniques
should be used
• Requirement Engineering means that requirements for a product
are defined, managed and tested systematically
– Is the process of establishing the services that are required of the
system, the constraints under which it operates and is developed.
– It covers all activities involved in discovering, documenting and
maintaining a set of requirements for a computer- based system.
– Helps software engineers to better understand the problem they will
work to solve.
– can influence the development cost, time, effort and quality.
….
• It is essential that the software engineering team understand
the requirements of a problem before the team tries to solve
the problem.
• In some cases requirements engineering may be abbreviated,
but it is never abandoned.
• RE is software engineering actions that start with
communication activity and continues into the modeling
activity.
• RE establishes a solid base for design and construction.
Without it, resulting software has a high probability of not
meeting customer needs.
Types of Requirements
1) User and System Requirements

User requirements
– Often referred to as user needs, describe what the user
does with the system, such as what activities that
users must be able to perform.
– Are statements, in a natural language plus diagrams, of
what services the system is expected to provide and the
constraints under which it must operate.
– The term user requirements to mean high-level abstract
requirements of what the system should do
System requirements
– system requirements to mean the detailed description of what
the system should do
– set out the system’s functions, services and operational
constraints in detail.
– The system requirements document (sometimes called a
functional specification).
– It should define exactly what is to be implemented.
– It may part of the contract between the system buyer and the
software developers.
– System requirements are the building blocks developers use
to build the system.
– System requirements may be expressed using system models
• System specification
– A detailed software description which can serve as a basis
for a design or implementation.
– Bridges the gap between requirements and design.
– Written for developers
User and system requirements
• Example 1 : Mental Health Care Patient management system
(MHC-PMS)
User requirement definition
1. The MHC-PMS shall generate monthly management reports showing

the cost of drugs prescribed by each clinic during that month
System requirements Specification

1.1 On the last working day of each month, a summary of the drugs prescribed, their cost
and the prescribing clinics shall be generated
1.2 The system shall automatically generate the report for printing after 17:30 on the last
working day of the month.
1.3 A report shall be created for each clinic and shall list the individual drug names, total
number of prescriptions, the number of doses and total costs of the prescribed drugs
1.4 If drugs are available in different dose units (e.g. 1omg, 20mg, etc.) separate reports
shall be created for each dose unit.
1.5 Access to all cost reports shall be restricted to authorized users
…
• Example 2 : Employee Attendance System
User Requirement Definition

• Biometric Attendance System is used to track the employee’s entry
and exit time.
System Requirement Specification

• The system will automatically download the data from the biometric
devices after 1730.
• The report will be generated for each employee that contain his entry
& exit time
• The system will generated the detail report of the employees showing
his working hours for a day or a week.
• The system will show the list of individual who are coming late and
going early on daily, weekly & monthly basis
• Different levels of system specification are useful because
they communicative information about the system to
different types of readers.
Client Managers
System end-users
User Requirements
Client engineers
Contractor managers
System Architects
Re
q
uir
System end-users
em
Client engineers
en
System Requirements
ts
System Architects
re
Software developers
dea
rs
Software design Client engineers
Specification System Architects
Software developers
2) Functional and Non-functional Requirements
• Software system requirements are often classified as
functional requirements, non-functional requirements.
• Functional requirements - related to functional aspect of
software
– Are statements of services the system should provide
– How the system should react to particular inputs
– How the system should behave in particular situations.
– In some cases, the functional requirements may also explicitly
state what the system should not do.
• Functional requirements describe functionality or system
services.
– What inputs the system should accept?
– What outputs the system should produce?
– What data the system should store that other systems might
use?
– What computations the system should perform?
– The timing and synchronization of the above
• Examples:
– The user shall be able to search either all of the initial set of
databases or select a subset from it.
– The system shall provide appropriate viewers for the user to read
documents in the document store.
– Every order shall be allocated a unique identifier, which the user
shall be able to copy to the account’s permanent storage area.
• Functional requirements for the MHC-PMS
– A user shall be able to search the appointments lists for all
clinics.
– The system shall generate each day, for each clinic, a list of
patients who are expected to attend appointments that
day.
– Each staff member using the system shall be uniquely
identified by his or her 8-digit employee number.
• Non-functional requirements- are not related to functional
aspect of the software.
– Are constraints on the services or functions offered by the
system.
– They include timing constraints, storage requirements,
reliability constraints on the development process and
standards.
– Non-functional requirements often apply to the system as
whole. They do not usually just apply to individual system
features or services.
• Non-functional requirements may be more critical than
functional requirements.
– If these are not met, the system is useless
• Non-functional requirements may be very difficult to state
precisely and imprecise requirements may be difficult to verify.
The types of non-functional requirements are:
• Product requirements
– Requirements which specify that the delivered product must
behave in a particular way(specify product behaviour)
• Example include performance requirements on how fast the
system must execute and how much memory it requires;
reliability requirements that set out the acceptable failure rate;
portability requirements; and usability requirements.
• Organisational requirements
– Requirements which are a consequence of organisational
policies and procedures e.g. process standards used,
implementation requirements, etc.
• The programming language or design method used; and delivery
requirements that specify when the product and its
documentation are to be delivered.
• External requirements
– Requirements which arise from factors which are external to
the system and its development process e.g. interoperability
requirements, legislative requirements, etc.
• These may include interoperability requirements that define
how the system interacts with systems in other organization;
legislative requirements that must be followed to ensure that
the system operates within the law; and ethical requirements.
….
• Examples of nonfunctional requirements in the MHC-PMS
Product requirement
The MHC-PMS shall be available to all clinics during normal working hours
(Mon–Fri, 0830–17.30). Downtime within normal working hours shall not
exceed five seconds in any one day.
Organizational requirement
Users of the MHC-PMS system shall authenticate themselves using their
health authority identity card.
External requirement
The system shall implement patient privacy provisions as set out in HStan-03-
2006-priv.
Non-functional requirement types
Metrics for specifying non-functional requirements
Property Measure
Speed Processed transactions/second
User/Event response time
Screen refresh time
Size K Bytes
Number of RAM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems
Non functional requirements for Satwatch
• Any user who knows how to read a digital watch and understands
international time zone abbreviations should be able to use
satwatch without the user manual.(Usability requirement)
• As the satwatch has no buttons, no software faults requiring the
resetting of the watch should occur(Reliability requirement).
• Satwatch should display the correct time zone within 5 minutes of
the end of a GPS blackout period.[performance requirement]
• Satwatch should measure time within 1/100th second over 5 years.
[Performance requirement]
• Satwatch should display time correctly in all 24 time zones.
[performance requirement]
• Satwatch should accept upgrades to its onboard via the webify
watch serial interface.[supportability requirement]
Constraints for satwatch
• All related software associated with Satwatch, including

the onboard software, will be written using java, to
comply with current company policy.[implementation
requirement]
• Satwatch complies with the physical, electrical, and
software interfaces defined by webify watch API 2.0.
[Interface requirement]
Domain requirements
• Domain requirements are derived from the application
domain rather than from specific needs of system users.
• Describe system characteristics and features that reflect
the domain
• They usually include specialized terminologies or
reference to domain concept.
• They may be new
– functional requirements,
– constraints on existing requirements or
– define specific computations.
• If domain requirements are not satisfied, the system may
be unworkable.
• Example: Library System domain requirements
– There shall be a standard user interface to all databases
which shall be based on the Z39.50 standard.
• is design constraint that specifies user interface to the
database must be implemented according to specific library
standard.
– Because of copyright restrictions, some received on-line
documents must be deleted immediately after arrival.
Depending on the user’s requirements, these documents
will either be printed locally on the system server for
manually forwarding to the user or routed to a network
printer.
Domain Requirement Issues
• Understandability
– Requirements are expressed in the language of the
application domain.
 This is often not understood by software engineers developing the
system.
– Involvement of domain expert may resolve the problem.
• Implicitness
– Domain specialists understand the area so well that they do
not think of making the domain requirements explicit.
Requirement Engineering
• Goal: Obtain and understand software requirements in a
complete, consistent and accurate way, and generate
software requirement specification (SRS) document.
• Scope:
– Communication
– Planning Requirement
Engineering
– Modeling
• Analysis of requirements
• Design of software
– Construction
• Coding
• Testing
– Deployment
Requirement Engineering process
• The processes used for RE vary widely depending on the
application domain, the people involved and the
organisation developing the requirements.
• However, there are a number of generic activities common
to all processes
– Feasibility studies
– Requirements elicitation and analysis
– Requirement specification
– Requirements validation
– Requirements change management
RE Process…
Feasibility
study
Determining
if running the
project is
feasible
Feasibility Study
• A feasibility study decides whether or not the proposed

system is worthwhile.
• A short focused study that checks;
– If the system contributes to organisational objectives;
– If the system can be engineered using current technology
and within budget;
– If the system can be integrated with other systems that
are used.
…
• Based on information assessment (what is required),
information collection and report writing.
• Questions for people in the organisation
– What if the system wasn’t implemented?
– What are current process problems?
– How will the proposed system help?
– What will be the integration problems?
– Is new technology needed? What skills?
– What facilities must be supported by the proposed system?
Requirements elicitation & Analysis
• Requirements elicitation is the practice of collecting the
requirements of a system from users, customers and other
stakeholders.
• Sometimes referred to as "requirements gathering“ or
requirements discovery.
• Involves technical staff working with other stakeholders to find
out about
• The application domain
• The services that the system should provide
• The system’s operational constraints
• Multi-disciplinary and human-centred activity.
• The most difficult, most critical, most error-prone, and most
communication-intensive aspect of software development.
• Requirement Analysis has some tool support
– E.g. RequisitePro, MS Visio
Why Requirement elicitation & analysis is difficult?
• Problems of scope:
– The boundary of the system is ill-defined.
– Customers/users specify unnecessary technical detail that may
confuse rather than clarify objectives.
• Problem of understanding:
– Customers are not completely sure of what is needed.
– Customers have a poor understanding of the capabilities and
limitations of the computing environment.
– Customers don’t have a full understanding of their problem
domain.
– Customers have trouble communicating needs to the system
engineer.
…
– Customers omit detail that is believed to be obvious.
– Customers specify requirements that conflict with other
requirements.
– Customers specify requirements that are ambiguous or not
able to test.
– Stakeholders naturally express requirements in their own
terms.
– Different stakeholders have different requirements.
• Problems of volatility:
– Requirement change over time. New requirement may
emerge
• Political factors may influence the requirements of the
system.
• Requirements elicitation & analysis process activities
involves:
– Domain understanding
– Requirement collection
– Classification (into coherent clusters)
– Conflict resolution and identification of unpractical
requirements
– Prioritization
– Requirement checking (e.g. Eliminate, combined and
modified requirements)
Requirements analysis
• The process of breaking down user requirements into their
components and studying these to develop a set of system
requirements.
• The three major goals of this process are:
– Achieve agreement among developers and customers.
– Provide a basis for design.
– Provide a basis for Verification and Validation (V&V)
• Different models may be produced during the requirements
analysis activity.
• Requirements analysis may involve three structuring activities
which result in these different models
– Partitioning. Identifies the structural (part-of) relationships between entities
– Abstraction. Identifies generalities among entities
– Projection. Identifies different ways of looking at a problem
• System models are covered in detail later.
Requirements elicitation Techniques
• Requirements Elicitation is the process to find out the
requirements for an intended software system by
communicating with client, end users, system users and others
who have a stake in the software system development.
 There are various ways to discover requirements
 Interview
 Brainstorming
 Prototyping
 Delphi Technique
 Ethnography
 Scenarios
 Use cases
Interview
• Conducted through formal or informal interviews, the RE
team puts questions to stakeholders about the system
that they use (if any) and the system to be developed.
– Ask about specific details
– about the stakeholder’s vision for the future
– Ask if they have alternative ideas
– Ask for other sources of information
– Ask them to draw diagrams
• Don’t ask questions like ‘what do you want’.
...
• Interviewers should be open-minded, willing to listen to
stakeholders and should not have pre-conceived ideas
about the requirements.
• There are two types of interview
– Closed interviews where a pre-defined set of questions are
answered.
– Open interviews where there is no pre-defined agenda
and a range of issues are explored with stakeholders.
• Normally a mix of closed and open-ended interviewing
are used together.
…
• Interviews are good for getting an overall understanding
of what stakeholders do and how they might interact
with the system.
• Interviews are not good for understanding domain
requirements.
– Requirements engineers cannot understand specific
domain terminology;
– Some domain knowledge is so familiar that people find it
hard to articulate or think that it isn’t worth articulating.
Brainstorming
• Brainstorming refers to the process of systematic and

liberal generation of a large volume of ideas from a number
of participants.
• In a brainstorming session you (moderator) gather together
a group of people, create a stimulating and focused
atmosphere, and let people come up with ideas without
risk of being ridiculed.
• The facilitator notes down all ideas on a whiteboard.
• Joint Application Development (JAD) is a technique based

on intensive brainstorming sessions.
Prototyping
• Software customers and end users usually find it very

difficult to express their real requirements
• Prototyping provide insight to the new functionalities by
demonstrating a new prototype
– The simplest kind: paper prototype.
• a set of pictures of the system that are shown to users
in sequence to explain what would happen
– The most common: a mock-up of the system’s User Interface
• Written in a rapid prototyping language
• Does not normally perform any computations, access any
databases or interact with any other systems
• May prototype a particular aspect of the system
• Can be combined with other techniques
Prototyping…
Delphi Technique
• The Delphi technique is an iterative technique in which
information is exchanged in a written form until a
consensus is reached.
• For example participants may write down their
requirements, sorted in order of importance.
• The sets of requirements obtained are distributed to all
participants, who reflect on them to obtain a revised
set of requirements.
• The procedure will be repeated several times until
sufficient consensus is reached .
Ethnography
• Ethnography is an observational technique that
can be used to understand social and organizational
requirements.
• A social scientists spends a considerable time observing
and analysing how people actually work.
• People do not have to explain or articulate their work.
• Social and organisational factors of importance may be
observed.
• Ethnographic studies have shown that work is usually
richer and more complex than suggested by simple
system models.
Other requirement elicitation techniques involves:
– Read documents (organizational charts, procedures,
rules, etc), manuals (user or operational manuals) and
discuss requirements with users
– Shadowing important potential users as they do their
work
• ask the user to explain everything he or she is doing
– Session videotapeing
Scenarios
• Scenarios are descriptions of how a system is used in
practice.
• They are helpful in requirements elicitation as people can
relate to these more readily than abstract statement of
what they require from a system.
• Scenarios are particularly useful for adding detail to an
outline requirements description
• Scenarios descriptions include
A description of the starting situation;
A description of the normal flow of events;
A description of what can go wrong;
Information about other concurrent activities;
A description of the state when the scenario finishes.
Scenario Example: ATM
• Scenario
– Tiruwork uses an ATM
– She enters her card and PIN into the ATM
– She requests withdrawal of 4000 ETB
– Tiruwork receives a printed receipt, takes out her bank
card and the money and leaves
• Observations
– Describes a single instance of using the system
– Does not describe all possible ways the system can be
used
Use cases
• Use cases are a scenario-based technique for describing

requirements
• Use cases are more effective in capturing functional
requirements
• Use cases identify the users of the system (actors)
• Use cases identify the tasks (use cases)
• Use cases relate the users and the tasks
• Use cases are typically illustrated with UML as stick figures or
similar diagrams
– UML (unified Modelling Language) is a standard for modelling object-
oriented software requirements and design.
• A set of use cases should describe all possible interactions with
the system
• Sequence diagrams may be used to add detail to use-cases by
showing the sequence of event processing in the system.
Use Case Example: Withdraw
Withdraw
<<include>>
Authenti
cate
. <<include>> stereotype to include use cases

 Details in textual description
Example: Withdraw Use Case Event Flow
Actor steps System steps

1. Authenticate 2.ATM displays options
3. Client selects “Withdraw” 4. ATM queries amount
5. Client enters amount 6. ATM returns bank card

7. ATM outputs specified amount in ETB
Requirements Specification
• The end product of requirements elicitation and analysis is the
requirements specification.
– i.e. . Requirement phase ends with a software requirement
specification(SRS) document
• It is a vital piece of documentation that is crucial to the success
of any software development project.
• If we cannot precisely state what the system should do, then
how can we develop the software with any confidence, and
how can we hope to check that the end product meets its
needs?
• The specification is the reference document against which all
subsequent development is assessed.
Req. Specification…
• It is the process of writing down the user and system
requirements in a requirements document.
– i.e. contractual document between client and development
organization
• The requirements are captured or expressed or articulated, in a
software requirements specification.
• A document that clearly and precisely describes essential
requirements of software and external interfaces(functions,
performance, quality etc)
• A software requirements specification(SRS)- a formal document
as the output of the specification stage.
• It is a complete description of the behavior of a system to be
developed
….
• It is NOT a design document. As far as possible, it should set
of WHAT the system should do rather than HOW it should
do it
• Should include both a definition and a specification of
requirements.
• Specification can be –
– Written Document
– A set of graphical models,
– A formal mathematical models
– Collection of usage scenario.
– A prototype
– Combination of above.
…
• The Formality and format of a specification varies with the size
and the complexity of the software to be built.
• For large systems, written document, language descriptions, and
graphical models may be the best approach.
• For small systems or products, usage scenarios
• The requirements document should
– specify external system behaviour
– specify implementation constraints
– easy to change(but changes must be managed)
– serve as reference tool for maintenance
– record forethought about the life cycle of the system (i.e. predict
changes)
– characterise responses to unexpected events
• The requirements document has diverse set of users ranging.
…
• Specification Principles
– Separate functionality from implementation
– Develop model of desired behavior of the system
– Establish the context in which software operates
– Define the environment in which system operate
• Need for SRS
– SRS establishes basis of agreement between the user and the
developer
– Helps user understand his needs
– SRS provides a reference for validation of the final product
– High quality SRS essential for high Quality SW
– Good SRS reduces the development cost
• Issues SRS writer address/ SRS contains
– Functional requirements
– Non-functional requirements
– Constraints
– External interfaces
– Attributes
– Performance
– Development Methodology
Users of a requirements document
Specify the requirements and
read them to check that they
System customers meet their needs. They
specify changes to the
requirements
Use the requirements

Managers document to plan a bid for
the system and to plan the
system development process
Use the requirements to

System engineers understand what system is to
be developed
System test Use the requirements to

engineers develop validation tests for
the system
System Use the requirements to help

maintenance understand the system and
engineers the relationships between its
parts
…
• Guidelines for writing Requirement Specification
– User requirements must be written in natural languages because
they have to be understood by people who are not technical
experts.
– Invent a standard format and use it for all requirements.
– Use language in a consistent way. Use shall for mandatory
requirements, and should for desirable requirements.
– Use text highlighting to identify key parts of the requirement.
– Avoid the use of computer jargon.
Problems with natural language
• Lack of clarity & Ambiguity
– Precision is difficult without making the document clear to read;
readers and writers may not interpret words in the same way
• Over-flexibility
– – The same thing may be expressed in a number of different
ways
• Requirements amalgamation & confusion
– – Several different requirements may be expressed together;
functional and non-functional requirements may be mixed together
• Lack of modularization
– – NL structures are inadequate to structure system requirements
Alternatives to natural language
• To avoid/minimize limitations of NL specification we have

the following alternative.
– Structured natural language
• depends on defining standard forms or templates to express
requirements specification
• E.g. Form-based node specification
– Design description languages
• similar to programming languages but with additional, more
abstract features
• E.g. Program Description language (PDL)
– Graphical notations
• a graphical language, supplemented by text annotations, is used
to define functional requirements (e.g. use-case diagrams
• Mathematical/formal specifications
– based on mathematical concepts such as finite-state
machines or sets; unambiguous specifications reduce
arguments between customers and contractors but most
customers don't understand formal specifications
Example: structured Natural Language
Design description languages
• uses a language like a programming language but with
more abstract features to specify the requirements by
defining an operational model of the system.
• E.g. Program Description language (PDL)
– PDL- is a language derived from a programming language like
Java and Ada.
– PDLs results in a very detailed specifications and, sometimes,
they are too close to the implementation for inclusion in a
requirement document.
– This notation is only understandable to people with
programming language knowledge
Example: Part of an ATM specification in PDL
Graphical notations
 A graphical language, supplemented by text annotations is used
to define the functional requirements for the system.
Examples: Structured Analysis and Design Technique (SADT) and
use-case descriptions.
Mathematical specifications
notations based on mathematical concepts such as finite-state
machines or sets.
Is unambiguous specifications which reduce the arguments
between customer and contractor about system functionality.
However, most customers don’t understand formal specifications
and are reluctant to accept it as a system contract.
Characteristics of a good SRS
• Correct
– Every requirement given in SRS accurately represent some
desired feature in the final system.
– Accurately represent client wishes
• Complete
– all desired features and scenarios are described or specified
• Unambiguous
– Each requirement has exactly one interpretation. It should
be clear and understandable
• Consistent
– No two requirements contradict one another. Should have
internal consistency
…
• Verifiable
– There must exist a cost effective way of checking if SW meets the
requirement or requirements can be tested
• Modifiable
– SRS must be structured to permit effective Modifications(e g. Don’t be
redundant, keep requirements separate)
• Traceable
– Each requirement can be traced through software development to its
corresponding system functions, and vice versa
• This is critical for testing and change evaluation
• Ranked for importance (i.e. essential vs. desirable)

– Needed for prioritizing in construction
– To reduce risks due to changing requirements
Structure of an SRS
• A number of large organizations, such as the US department of

defense and the IEEE, have defined standards for requirements
documents
• Recommended approaches for the specification of software
requirements are described by IEEE 830-1998.
• This IEEE standard suggests the following structure for
requirements documents:
IEEE requirements standard/Template
1. Introduction
1.1 Purpose of the Product
1.2 Scope of the Product
1.3 Acronyms, Abbreviations, Definitions
1.4 References
1.5 Outline of the rest of the SRS
2. Over all description
2.1 Product Perspective
2.2 Product Functions
2.3 User Characteristics
2.4 Constraints
2.5 Assumptions and Dependencies
3. Specific Requirements
3.1 External Interface Requirements
3.1.1 User Interfaces
3.1.2 Hardware Interfaces
3.1.3 Software Interfaces
3.1.4 Communications Interfaces
3.2 Functional Requirements
3.2.1 Class 1
3.2.2 Class 2
…
3.3 Non-Functional requirements
3.4 Other Requirements
4. Appendices
5. Index
Project2
Construct SRS Document for the
proposal that you have developed
so far
Due date: may 05,2016
Requirements validation
• Checks the software requirement specification against
stakeholders goals and requirements.
• Ensuring that the set of requirements are correct, complete &
consistent
• Concerned with demonstrating that the requirements define the
system that the customer really wants.
• Requirements error costs are high so validation is very important
– Fixing a requirements error after delivery may cost up to 100 times
the cost of fixing an implementation error.
• Ensuring that a model can be created that satisfies the
requirements.
• Ensuring that a real-world solution can be built and tested to
prove that it satisfies the requirements.
…
• During the requirements validation process, different types

of checks should be carried out on the requirements in the
requirement document.
– Validity. Does the system provide the functions which best
support the customer’s needs?
– Consistency. Are there any requirements conflicts?
– Completeness. Are all functions required by the customer
included?
– Realism. Can the requirements be implemented given
available budget and technology?
– Verifiability. Can the requirements be checked?
.....
• Requirements validation techniques
– Requirements reviews
• Systematic manual analysis of the requirements.
– Prototyping
• Using an executable model of the system to check
requirements.
– Test-case generation
• Developing tests for requirements to check testability.
– Automated consistency analysis
• Checking the consistency of a structured requirements
description
….
• Requirements Verification & Validation: Objectives
– Certify that the requirements document is an acceptable
description of the system to be implemented
– Check requirements document for:
• Correctness, completeness and consistency
• Conformance to standards
• Requirement conflicts
• Technical errors
• Ambiguous requirements
…
• Requirements: Analysis & Validation
– Analysis works with raw requirements as elicited from
the system stakeholders.
• “Have we got the right requirements?” is the key question
to be answered at this stage
– Validation works with final draft of the requirements
document i.e. with negotiated and agreed requirements.
• “Have we got the requirements right?” is the key question
to be answered at this stage
Requirements Management
....
• Requirement management is the process of managing changes
to a system’s requirements during the requirements
engineering process and system development.
– Set of activities that help project team to identify, control, and track
requirements and changes as project proceeds
• Requirements evolve because of changes to a system’s
environment and as customers develop a better understanding
of their real needs.
• New requirements emerge and existing requirements change at
all stages of the system development process and a better
understanding of the system is developed;
• The impact of proposed change to requirements must be
assessed and, as requirements changes are accepted, the
system design and implementation must then be modified.
….
• The principal concerns of requirements management are:

– Managing changes to agreed requirements
– Managing the relationships between requirements
– Managing the dependencies between the requirements
document and other documents produced during the systems
and software engineering process.
– Identify changes in requirement
…
• Requirements change for the following reasons:
– The priority of requirements from different viewpoints changes
during the development process.
– System customers may specify requirements from a business
perspective that conflict with end-user requirements (business
process changes).
– The business and technical environment of the system changes
during its development (technology changes).
– Changes to system requirements may be due to errors and
misunderstandings in the requirements engineering process, design
or implementation problems (the problem become better
understood).
– New requirements may emerge as stakeholders develop a better
understand in of the system.
– Most commonly, requirements change is a result of changing
external circumstances.
Requirements Management Plan
• A component of Project Management Plan
• Details the plans and processes for managing requirements
through out the entire project life cycle
• During the requirements engineering process, you have to plan:
– Requirements identification: How requirements are individually
identified;
– A change management process: The process followed when
analysing a requirements change;
– Traceability policies: The amount of information about
requirements relationships that is maintained;
– CASE tool support: The tool support required to help manage
requirements change;
...
• Traceability is concerned with the relationships between
requirements, their sources and the system design
– Source traceability
• Links from requirements to stakeholders who proposed these
requirements;
– Requirements traceability
• Links between dependent requirements;
– Design traceability
• Links from the requirements to the design;
....
• Change management should apply to all proposed changes
to the requirements.
• Principal stages
– Problem analysis. Discuss requirements problem and propose
change;
– Change analysis and costing. Assess effects of change on
other requirements;
– Change implementation. Modify requirements document and
other documents to reflect change.
Summary
• Requirements set out what the system should do and
define constraints on its operation and implementation
• Functional requirements set out services that the system
should provide
• Non-functional requirements describes quality aspect of
the system being developed .
• User requirements are high-level statements of what the
system should do
• User requirements should be written using natural
language, tables and diagrams
• System requirements are intended to communicate the
functions that the system should provide
• System requirements may be written in structured natural
language, a PDL or in a formal language
• The requirements engineering process includes a feasibility
study, requirements elicitation and analysis, requirements
specification, requirement validation and requirements
management.
• Requirements elicitation and analysis is iterative involving
domain understanding, requirements collection,
classification, structuring, prioritisation and validation.
• Systems have multiple stakeholders with different
requirements.
• Social and organisation factors influence system
requirements.
• Requirements validation is concerned with checks for
validity, consistency, completeness, realism and verifiability.
• Business changes inevitably lead to changing requirements.
• Requirements management includes planning and change
management.
• A software requirements document is an agreed statement of the
system requirements

SE Activity 5& 6

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SE Activity 5& 6

Uploaded by

Copyright:

Available Formats

Software Engineering

Software Requirement Engineering

1) User and System Requirements

1. The MHC-PMS shall generate monthly management reports showing

System requirements Specification

User Requirement Definition

System Requirement Specification

• All related software associated with Satwatch, including

• A feasibility study decides whether or not the proposed

• Brainstorming refers to the process of systematic and

• Joint Application Development (JAD) is a technique based

• Software customers and end users usually find it very

• Use cases are a scenario-based technique for describing

. <<include>> stereotype to include use cases

Actor steps System steps

3. Client selects “Withdraw” 4. ATM queries amount

5. Client enters amount 6. ATM returns bank card

Use the requirements

Use the requirements to

System test Use the requirements to

System Use the requirements to help

• To avoid/minimize limitations of NL specification we have

• Ranked for importance (i.e. essential vs. desirable)

• A number of large organizations, such as the US department of

Due date: may 05,2016

• During the requirements validation process, different types

• The principal concerns of requirements management are:

You might also like