Course Title: Software Engineering
Course Contents
Unit-2:
1. Software Requirements
1.1. Introduction
1.2. Types of Requirements
1.3. Requirements Engineering Process
1.4. Feasibility study
1.5. Requirements elicitation and analysis
1.6. Requirement validation
1.7. Requirement management
Course Contents
Unit-2:
2. Software Prototyping
2.1. Introduction
2.2. Prototyping in the Software process
2.3. Rapid Prototyping Techniques
2.4. User Interface Prototyping
3. Formal Specification
3.1. Introduction
3.2. Formal Specification in Software Process
3.3. Interface Specification
3.4. Behavioural Specification
Let’s Start : Unit-2
Software Requirements?
Objectives:
⚫ To introduce the concepts of user and system
requirements for software system.
⚫ Explain different ways of expressing software
requirements.
⚫ To explain how software requirements may be
organised in a requirements document
Software Requirements?
Software requirements:
⚫ System requirements for a system are the
descriptions of the services provided by the system
and its operational constraints.
⚫ Need of customer for a system.
⚫ The process of finding out, analysing, documenting
and checking the services and constraints of system
is called Requirements Engineering (RE).
⚫ In some cases, a requirements is simply a high-level,
abstract statement of a service that the system should
provide or a constraint on the system.
Software Requirements?
What is requirements?
Requirements may serve a dual function
⚫ The requirements must be written so that several
contractors can bid for the contract, offerings,
meeting the client organisation’s needs.
⚫ Once awarded, the contractor must write a system
definition for the client in more details so that the
client understands and can validate what the software
will do.
Both of these documents may be called the requirements
document for the system.
Software Requirements?
Types of Requirement?
A software requirement can be of 3 types:
• Functional requirements
• Non-functional requirements
• Domain requirements
Software Requirements?
Functional Requirement?
A software requirement can be of 3 types:
• Functional requirements
• Non-functional requirements
• Domain requirements
Software Requirements?
Functional Requirement.
⚫ These are the requirements that the end user
specifically demands as basic facilities that the
system should offer.
⚫ All these functionalities need to be necessarily
incorporated into the system as a part of the contract.
⚫ These are represented or stated in the form of input to
be given to the system, the operation performed and
the output expected.
⚫ They are basically the requirements stated by the user
which one can see directly in the final product, unlike
the non-functional requirements.
Software Requirements?
Functional Requirement? Example
⚫ In a hospital management system, a doctor should be
able to retrieve the information of his patients.
⚫ Each high-level functional requirement may involve
several interactions or dialogues between the system
and the outside world. In order to accurately describe
the functional requirements, all scenarios must be
enumerated.
⚫ There are many ways of expressing functional
requirements e.g., natural language, a structured or
formatted language with no rigorous syntax and
formal specification language with proper syntax.
Software Requirements?
Non-Functional Requirement?
⚫ These are basically the quality constraints that the
system must satisfy according to the project contract.
⚫ The priority or extent to which these factors are
implemented varies from one project to other.
⚫ They are also called non-behavioral requirements.
⚫ Non-functional requirements may be more critical
than functional requirements. If these are not met, the
system is useless.
Software Requirements?
Non-Functional Requirement?
They basically deal with issues like:
⚫ Portability
⚫ Security
⚫ Maintainability
⚫ Reliability
⚫ Scalability
⚫ Performance
⚫ Reusability
⚫ Flexibility
Software Requirements?
Non-Functional Requirement?
NFR’s are classified into following types:
1. Product Requirements : These requirements specify
product behaviour. E.g Performance, memory,
reliability
2. Organisational Requirements: Derived from policies
and procedures in the customer’s and developer’s
organisation.
3. External Requirements: Requirements that are
derived from factors external to the system and its
development process.
Software Requirements?
Non-Functional Requirement?
Software Requirements?
Examples of Functional & Non-Functional
Requirement?
⚫ See file for Functional & Non-Functional
• <02 SRS Example document- Amazing Restaurant Finder>
⚫ Also see files for sample of writing SRS
Document:
• 00 How to write SRS document
• 01 SRS Template IEEE Standard
Software Requirements?
Domain Requirements?
⚫ Domain requirements are derived from the
application domain of the system rather than
from the specific needs of the system users.
⚫ Domain requirements are important because
they often reflect fundamentals of the
application domain. Example of library system:
User interface of library databases should be
based on the Z39.50 standard.
Don’t let the book to print because of the
copyright restriction.
Software Requirements?
Domain requirements problems?
Understandability:
⚫ Requirements are expressed in the language of
the application domain.
⚫ This is often not understood by software
engineers developing the system.
Implicitness:
⚫ Domain specialists understand the area so well
that they do not think of making the domain
requirements explicit.
Software Requirements?
Level of Description of Requirement?
1. User Requirements
2. System requirements
1. User Requirements:
⚫ High level abstraction requirements.
⚫ Requirements are statements, in a natural language plus
diagram of what services the system is expected to provide
and the constraints under which it must operate.
⚫ The user requirements for a system should describe the
functional and non-functional requirements so that they are
understandable by system users without detailed technical
knowledge.
Software Requirements?
1. User Requirements:
Guidelines for writing requirements.
To minimize misunderstanding in user requirements, follow
guidelines as:
⚫ Invent a standard format and use it for all Requirements
⚫ Use language in a consistent way. Use shall for mandatory
requirements, should for desirable requirements
⚫ Use text highlighting to identify key parts of the requirement
⚫ Avoid the use of computer jargon
Software Requirements?
2. System requirements:
⚫ More detailed specifications of user requirements
⚫ Serve as a basis for designing the system
⚫ May be used as part of the system contract
⚫ System requirements may be expressed using system
models.
Software Requirements?
2. System requirements: (Requirements and design)
⚫ In principle, requirements should state what the
system should do and the design should describe
how it does this.
⚫ In practice, requirements and design are inseparable
• A system architecture may be designed to structure the
requirements
• The system may inter-operate with other systems that
generate design requirements
• The use of a specific design may be a domain requirement
Software Requirements?
2. System requirements:
⚫ System requirements set out the system’s functions,
services and operational constraints in details.
⚫ The system requirements documents ( Functional
specification) should be precise.
⚫ It should define exactly what is to be implemented.
⚫ It may be part of the contract between the system
buyer and the software developers.
Software Requirements?
⚫ Example:
⚫ 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. On the last working day of each month, a summary of
the drugs prescribed, their cost, and the prescribing
clinics shall be generated.
2. The system shall automatically generate the report for
printing after 17.30 on the last working day of the
month.
Software Requirements?
⚫ Readers of different levels of requirements:
Software Requirements?
Interface requirements:
⚫ A point where two systems, subjects, organisations
etc. meet and interact.
⚫ A device or program enabling a user to communicate
with a computer
⚫ A interface is a intersection between system and
environment.
⚫ Interface = system/environment
Software Requirements?
Interface requirements:
⚫ All software systems must operate with existing
systems that have already been implemented and
installed in an environment.
⚫ If the new system and existing systems must work
together, the interfaces of existing systems have to be
precisely specified.
⚫ These specifications should be defined early in the
process and included in the requirements documents.
Software Requirements?
Interface requirements:
⚫ Three types of interface may have to be defined
• Procedural interfaces
• Data structures that are exchanged
• Data representations
Formal notations are an effective technique for interface
specification
Software Requirements?
Interface requirements:
Software Requirements?
The software requirements documents:
⚫ The software requirements documents ( also called
Software Requirements Specification or SRS) is the
official statement of what the system developers
should implement.
⚫ Include both the user requirements for a system and a
detailed specifications of the system requirements.
Software Requirements?
Users of a requirements document:
Software Requirements?
Requirements document structure:
• Introduction
• Glossary
• User requirements definition
• System architecture
• System requirements specification
• System models
• System evolution
• Appendices
• Index
Software Requirements?
Requirements document structure:
1. Introduction1.1 Purpose of the requirements document
1.2 Scope of the product
1.3 Definitions, acronyms and abbreviations
1.4 References
1.5 Overview of the reminder of the document
2. General Description2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 General constraints
2.5 Assumptions and dependencies
Software Requirements?
Requirements document structure:
3. Specific Requirements3.1 Functional requirements
3.2 Non- Functional requirements
3.3 Interface Requirements
………
Most substantial part of the documents but because of the wide
variability in organisational practices, it is not appropriate to
define a standard structure for this section.
The requirements may document external interfaces, describe
system functionality and performance, specify logical database
requirements, design constraints, emergent system properties and
quality characteristics.
Software Requirements?
Requirements document structure:
4. Appendices : Appendices contain material that is too detailed to
include in the main report, such as long mathematical
derivations or calculations, detailed technical drawings
etc
5. Index : An alphabetical list of names, subjects, etc. with
reference to the pages on which they are mentioned.
Course Contents
Unit-2:
1. Software Requirements
1.1. Introduction
1.2. Types of Requirements
1.3. Requirements Engineering Process
1.4. Feasibility study
1.5. Requirements elicitation and analysis
1.6. Requirement validation
1.7. Requirement Management
Requirements Engineering
Requirements Engineering Process
Requirements Engineering Process:
1. Feasibility study
2. Requirements elicitation and analysis
3. Requirements validation
4. Requirements management
Requirements Engineering
Requirements Engineering Process
Requirements Engineering Process:
⚫ Requirements engineering (RE) refers to the
process of defining, documenting, and maintaining
requirements in the engineering design process.
⚫ Requirement engineering provides the appropriate
mechanism to understand what the customer
desires, analysing the need, and assessing
feasibility, negotiating a reasonable solution,
specifying the solution clearly, validating the
specifications and managing the requirements as
they are transformed into a working system.
Requirements Engineering
Requirements Engineering Process
Requirements Engineering Process
⚫ Thus, requirement engineering is the disciplined
application of proven principles, methods, tools,
and notation to describe a proposed system's
intended behaviour and its associated constraints.
Requirements Engineering
Requirements Engineering Process
Requirements Engineering Process:
It is a four-step process, which includes –
1. Feasibility Study
2. Requirement Elicitation and Analysis
3. Software Requirement Specification
4. Software Requirement Validation
⚫ Software Requirement Management
Requirements Engineering
Requirements Engineering Process
Requirements Engineering Process:
It is a four-step process, which includes –
Requirements Engineering
Requirements Engineering Process
1. Feasibility study:
The objective behind the feasibility study is to
create the reasons for developing the software
that is acceptable to users, flexible to change
and conformable to established standards.
Requirements Engineering
Requirements Engineering Process
Type of Feasibility study:
1. Technical Feasibility - Technical feasibility evaluates
the current technologies, which are needed to
accomplish customer requirements within the time and
budget.
2. Operational Feasibility - Operational feasibility
assesses the range in which the required software
performs a series of levels to solve business problems
and customer requirements.
3. Economic Feasibility - Economic feasibility decides
whether the necessary software can generate financial
profits for an organization.
Requirements Engineering
Requirements Engineering Process
Feasibility study implementation:
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 Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
In this stage, SW engineers work with customers and
system end-users to find out about the application
domain, what services the system should provide, the
required performance of the system, hardware
constraints and so on.
⚫ What is Requirement Elicitation and Analysis and
what need to do in this phase?
⚫ Problems of Elicitation and Analysis ?
⚫ Elicitation and Analysis Process ?
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
This is also known as the gathering of requirements.
Here, requirements are identified with the help of
customers and existing systems processes, if
available.
Analysis of requirements starts with requirement
elicitation. The requirements are analysed to identify
inconsistencies, defects, omission, etc. We describe
requirements in terms of relationships and also resolve
conflicts if any.
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
Requirements Engineering Activities
Stakeholder
Participants
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
Requirement as "something that governs what, how well,
and under what conditions a product will achieve a given
purpose."
Functional requirements define "what" the system must
do, performance requirements define "how well" the
system must perform its functions, and a variety of other
requirements define "under what conditions" the system
must operate.
Requirements engineering covers all of the activities
needed to define and manage requirements shown in
above Figure.
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
Elicit means to evoke a response. You will have to do
some work to draw out the requirements from the
stakeholders and any existing documentation.
Analyse means to study or examine something in detail,
in order to discover more about it.
There are many different elicitation techniques that can
be used and are as follows:
• Viewpoints
• Interviewing
• Scenarios and Use-case
• Ethnography
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
⚫ Requirements elicitation also called requirements
discovery
⚫ Involves technical staff working with customers to
find out about the application domain, the services
that the system should provide and the system’s
operational constraints
⚫ May involve end-users, managers, engineers
involved in maintenance, domain experts, trade
unions, etc. These are called stakeholders
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
Problems of Elicitation and Analysis:
⚫ Getting all, and only, the right people involved.
⚫ Stakeholders don’t know what they really want
⚫ Stakeholders express requirements in their own terms
⚫ Different stakeholders may have conflicting requirements
⚫ Organisational and political factors may influence the system
requirements
⚫ The requirements change during the analysis process. New
stakeholders may emerge and the business environment
change
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
Elicitation and Analysis Process:
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
Requirements analysis process activities:
⚫ Domain understanding
⚫ Requirements collection
⚫ Classification
⚫ Conflict resolution
⚫ Prioritisation
⚫ Requirements checking
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
System models:
⚫ 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
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
Details of different elicitation techniques:
⚫ Viewpoints
⚫ Interviewing
⚫ Scenarios (Use-case diagram)
⚫ Ethnography
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
Viewpoint-oriented elicitation:
⚫ Stakeholders represent different ways of looking at a
problem or problem viewpoints
⚫ This multi-perspective analysis is important as there
is no single correct way to analyse system
requirements
⚫ Viewpoint analysis is that it can help recognize
different perspectives and provides a way for
discovering any possible conflicts in the requirements
proposed by different stakeholders.
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
Viewpoints:
A viewpoint is a collection of patterns, templates, and
conventions for constructing one type of view. It defines
the stakeholders whose concerns are reflected in the
viewpoint and the guidelines, principles, and template
models for constructing its views.
The example used here is an auto-teller system which
provides some automated banking services. Services include
cash withdrawal, message passing (send a message to
request a service), ordering a statement and transferring
funds.
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
Auto-teller viewpoints:
⚫ Bank customers
⚫ Representatives of other banks
⚫ Hardware and software maintenance engineers
⚫ Marketing department
⚫ Bank managers and counter staff
⚫ Database administrators and security staff
⚫ Communications engineers
⚫ Personnel department
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
Three Generic types of viewpoint:
1. Interactor viewpoints
People or other system that interact directly with the system
2. Indirect viewpoints
Who don’t use the system but influence the requirements i.e.
in the ATM system, management and security staff.
3. Domain viewpoints
Domain characteristics and constraints that influence the
system requirements. In the bank ATM system, standards for
interbank communications.
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
Viewpoint-oriented method (VORD):
⚫ VORD are used to identify the different user classes
and their viewpoints.
⚫ VOID is widely used approach to requirements
analysis
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
Viewpoint Oriented Requirement Definition (VORD):
⚫ Viewpoint identification
Discover viewpoints which receive system services and identify
the services provided to each viewpoint
⚫ Viewpoint structuring
Group related viewpoints into a hierarchy. Common services are
provided at higher-levels in the hierarchy
⚫ Viewpoint documentation
Refine the description of the identified viewpoints and services
⚫ Viewpoint-system mapping
Transform the analysis to an object-oriented design (i.e. use case)
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
VORD standard forms:
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
VORD standard forms:
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
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
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
Scenario descriptions:
⚫ System state at the beginning of the scenario
⚫ Normal flow of events in the scenario
⚫ What can go wrong and how this is handled
⚫ Other concurrent activities
⚫ System state on completion of the scenario
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
Event scenarios:
⚫ Event scenarios may be used to describe how a
system responds to the occurrence of some
particular event such as ‘start transaction’
⚫ VORD includes a diagrammatic convention for
event scenarios.• Data provided and delivered
• Control information
• Exception processing
• The next expected event
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
Event scenario - start transaction:
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
Scenario: Notation for data and control analysis:
⚫ Ellipses. data provided from or delivered to a
viewpoint
⚫ Control information enters and leaves at the
top of each box
⚫ Data leaves from the right of each box
⚫ Exceptions are shown at the bottom of each
box
⚫ Name of next event is in box with thick edges
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
Scenario: Exception description:
⚫ Most methods do not include facilities for
describing exceptions
⚫ In this example, exceptions are• Timeout. Customer fails to enter a PIN within the allowed
time limit
• Invalid card. The card is not recognised and is returned
• Stolen card. The card has been registered as stolen and is
retained by the machine
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
Use cases:
⚫ Use-cases are a scenario based technique in the UML
which identify the actors in an interaction and which
describe the interaction itself
⚫ 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
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
Use cases: Describing a Use Case
The description should include:
⚫ The name of the use case, which should summarize
its purpose
⚫ The actor or actors
⚫ The flow of events
⚫ Assumptions about entry conditions
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
Use cases: Describing a Use Case
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
Use cases: Describing a Use Case
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
Use cases: Describing a Use Case
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
Social and organisational factors:
⚫ Software systems are used in a social and
organisational context. This can influence or even
dominate the system requirements
⚫ Social and organisational factors are not a single
viewpoint but are influences on all viewpoints
⚫ Good analysts must be sensitive to these factors but
currently no systematic way to tackle their analysis
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
Ethnography: Social and organisational factors
Consider a system which allows senior management to
access information without going through middle
managers
• Managerial status. Senior managers may feel that they are
too important to use a keyboard. This may limit the type of
system interface used
• Managerial responsibilities. Managers may have no
uninterrupted time where they can learn to use the system
• Organisational resistance. Middle managers who will be
made redundant may deliberately provide misleading or
incomplete information so that the system will fail
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
Ethnography:
⚫ Ethnography is an observational technique that can
be used to understand social and organisational
requirements.
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
Ethnography:
⚫ 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
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
Ethnography effective for 2 types of requirements:
1. Requirements that are derived the way in which
people actually work rather than the way in which
process definitions say they out to work.
2. Requirements that are derived from cooperation and
awareness of other people’s activities.
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
Focused ethnography:
⚫ Combines ethnography with prototyping
⚫ Prototype development results in unanswered
questions which focus the ethnographic analysis
⚫ Problem with ethnography is that it studies existing
practices which may have some historical basis which
is no longer relevant
Requirements Engineering
Requirements Engineering Process
2. Requirement Elicitation and Analysis:
Ethnography and Prototyping:
Requirements Engineering
Requirements Engineering Process
3. Software Requirement Specification:
⚫ Software requirement specification is a kind of
document which is created by a software analyst
after the requirements collected from the various
sources - the requirement received by the customer
written in ordinary language.
⚫ It is the job of the analyst to write the requirement in
technical language so that they can be understood
and beneficial by the development team.
⚫ The models used at this stage include ER diagrams,
data flow diagrams (DFDs), Use-case diagram, data
dictionaries, etc.
Requirements Engineering
Requirements Engineering Process
3. Software Requirement Specification:
⚫ Data Flow Diagrams: Data Flow Diagrams (DFDs)
are used widely for modelling the requirements.
DFD shows the flow of data through a system. The
system may be a company, an organization, a set of
procedures, a computer hardware system, a
software system, or any combination of the
preceding. The DFD is also known as a data flow
graph or bubble chart.
Requirements Engineering
Requirements Engineering Process
3. Software Requirement Specification:
⚫ Data Dictionaries: Data Dictionaries are simply
repositories to store information about all data
items defined in DFDs. At the requirements stage,
the data dictionary should at least define customer
data items, to ensure that the customer and
developers use the same definition and
terminologies.
Requirements Engineering
Requirements Engineering Process
3. Software Requirement Specification:
⚫ Entity-Relationship Diagrams: Another tool for
requirement specification is the entity-relationship
diagram, often called an "E-R diagram." It is a
detailed logical representation of the data for the
organization and uses three main constructs i.e.
data entities, relationships, and their associated
attributes.
Requirements Engineering
Requirements Engineering Process
4. Software Requirement Validation:
⚫ After requirement specifications developed, the
requirements discussed in this document are
validated. The user might demand illegal,
impossible solution or experts may misinterpret the
needs.
⚫ 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
Requirements Engineering
Requirements Engineering Process
4. Software Requirement Validation:
Requirements checking:
⚫ 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 Engineering
Requirements Engineering Process
4. Software Requirement Validation:
Requirements validation techniques:
⚫ Requirements reviews:
⚫ 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 for the
consistency of structured requirements descriptions.
Requirements Engineering
Requirements Engineering Process
4. Software Requirement Validation:
Requirements reviews:
⚫ Regular reviews should be held while the
requirements definition is being formulated
⚫ Both client and contractor staff should be involved
in reviews
⚫ Reviews may be formal (with completed documents)
or informal. Good communications between
developers, customers and users can resolve
problems at an early stage
Requirements Engineering
Requirements Engineering Process
4. Software Requirement Validation:
Review checks:
⚫ Verifiability. Is the requirement realistically testable?
⚫ Comprehensibility. Is the requirement properly
understood?
⚫ Traceability. Is the origin of the requirement clearly
stated?
⚫ Adaptability. Can the requirement be changed
without a large impact on other requirements?
Requirements Engineering
Requirements Engineering Process
5. Software Requirement Management:
⚫ Requirements management is the process of
managing changing requirements during the
requirements engineering process and system
development.
⚫ Requirements are inevitably incomplete and
inconsistent
• New requirements emerge during the process as business
needs change and a better understanding of the system is
developed
• Different viewpoints have different requirements and these are
often contradictory
Requirements Engineering
Requirements Engineering Process
5. Software Requirement Management:
Requirements change:
⚫ 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
⚫ The business and technical environment of the
system changes during its development
Requirements Engineering
Requirements Engineering Process
5. Software Requirement Management:
Requirements evolution:
Requirements Engineering
Requirements Engineering Process
5. Software Requirement Management:
Enduring and volatile requirements:
⚫ Enduring requirements: Stable requirements
derived from the core activity of the customer
organisation. E.g. a hospital will always have
doctors, nurses, etc. May be derived from domain
models
⚫ Volatile requirements: Requirements which change
during development or when the system is in use. In
a hospital, requirements derived from health-care
policy
Requirements Engineering
Requirements Engineering Process
5. Software Requirement Management:
Classification of requirements:
⚫ Mutable requirementsRequirements that change due to the system’s environment
⚫ Emergent requirementsRequirements that emerge as understanding of the system develops
⚫ Consequential requirementsRequirements that result from the introduction of the computer system
⚫ Compatibility requirementsRequirements that depend on other systems or organisational
processes
Requirements Engineering
Requirements Engineering Process
5. Software Requirement Management:
Requirements management planning:
⚫ 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
Requirements Engineering
Requirements Engineering Process
5. Software Requirement Management:
Traceability:
⚫ There are relationship between the requirements, the
source of those requirements, and the system design
that should be recorded and how these records should
be maintained. Traceability maintained all these
information in a matrix tabular form and is called
traceability.
⚫ Traceability is the property of a requirements
specification that reflects the ease of finding related
requirements.
⚫ Traceability is used to track the requirements changes
Requirements Engineering
Requirements Engineering Process
5. Software Requirement Management:
Traceability:
There are 3 types of traceability information that may
be maintained.
1. Source traceability information – Who (Stakeholder)
proposed the requirements
2. Requirement traceability information: Dependent
requirements within the requirements document
3. Design traceability information: Links the
requirements to the design modules where these
requirements are implemented.
Requirements Engineering
Requirements Engineering Process
5. Software Requirement Management:
Traceability:
There are 3 types of traceability information that may
be maintained.
1. Source traceability information – Who (Stakeholder)
proposed the requirements
2. Requirement traceability information: Dependent
requirements within the requirements document
3. Design traceability information: Links the
requirements to the design modules where these
requirements are implemented.
Requirements Engineering
Requirements Engineering Process
5. Software Requirement Management:
Requirement Change management:
There are 3 types principle stages to a change
management process:
1. Problem analysis and change specification
2. Change analysis and costing
3. Change implementation
Top Related