ಬಿ.ಎಂ.ಎಸ್.

ತಂತ್ರಿ ಕ ಮತ್ತು ವ್ಯ ವ್ಸ್ಥಾ ಪನಾ ಮಹಾವಿದ್ಯಯ ಲಯ

BMS Institute of Technology and Management
(An Autonomous Institution Affiliated to VTU, Belagavi)
Avalahalli, Doddaballapur Main Road, Bengaluru – 560064

Department of Information Science and Engineering

Course Name: Software Engineering and Project Semester: V
Management
Course Code: BCS501 Faculty: Dr. Harish Kumar N
Module 2
Requirements Engineering: Functional and Non-functional requirements, Requirements
Engineering Processes. Requirements Elicitation and Analysis, Requirements Specification,
Requirements validation, Requirements change.

Requirements engineering definition: The process of establishing the services that the customer
requires from a system and the constraints under which it operates and is developed. The
requirements themselves are the descriptions of the system services and constraints that are
generated during the requirements engineering process. A requirement may range from a high-level
abstract statement of a service or of a system constraint to a detailed mathematical functional
specification. This is inevitable as requirements may serve a dual function as described in the
following scenarios:
1) May be the basis for a bid for a contract - therefore must be open to interpretation;
2) May be the basis for the contract itself - therefore must be defined in detail;
3) Both these statements may be called requirements.
Types of requirements:
Requirements can be basically categorized into:
1. User requirement which are statements in natural language plus diagrams of the services the
system provides & its operational constraints. Basically specifies external system behavior. These
are the requirements which are written for customers
2. Systems Requirements are a structured document setting out detailed descriptions of the
systems functions, services & operational constraints. It is necessary that the systems requirements
should reflect accurately what the customer wants and should also precisely define what should be
implemented. This could be a part of a contract between client and contractor
Example of a user requirement:
In a Library management system, the following functionalities are expected to be present
1. The system will maintain records of all library items including books,
serials, newspapers, magazines, video and audio tapes, reports, collections of
transparencies, computer discs and CD-ROMs.
2. Paper-based library items are stored on open shelves in the library and the system records their
reference position in the library.
3. No item will be removed from the library without the details of its borrowing being recorded in
the system.
4. All items will have a bar code containing a unique reference number by which an item can be
identified within the system.
For the same application the example of a System requirement could be:
1. The system will permit all users to search for an item by title, by author or by ISBN
2. Staff will be able to search for an item by bar code ref. number
3. Books can be borrowed for 15 days while CD-ROMs, Audio tapes & reports can be borrowed
only for 3 days
4. Borrowed items that are one day overdue in their return will cause a reminder letter to be
printed
5. Librarian should be able to find out details like Number of books & materials borrowed
(on a given day, by a given client)
6. Selected items may be temporarily blocked by authorized staff
 Readers of different types of requirements specification

Fig 11: Readers of requirements

Fig 11 shows that the users of User requirements and system requirements are generally the System
end-users, client engineers and system architects. Additionally, Contract managers and client
managers will be using the user requirements and the system requirements are the guiding path for
system developers.
Classification of requirements – Another way
1. Functional requirements: Statements of services the system should provide, how the system
should react to particular inputs and how the system should behave in particular situations. These
requirements may also state what the system should not do.
2. Non-functional requirements: Constraints on the services or functions offered by the system
such as timing constraints, constraints on the development process, standards, etc.
3. These requirements often apply to the system as a whole rather than individual features or
services.

4. Domain requirements: Constraints on the system from the domain of operation of the final
system.
Each of the above requirements is explained in detail.
Functional Requirements:
Describe functionality or system services and depend on the type of software, expected users and
the organization where the software is used. This could be high-level statements of what the
system should do. However, it should describe all the system services in detail which could include
its inputs, its Outputs, exceptions and so on. Such requirements are generally described in fairly
abstract but precise way.
Non-Functional Requirements:
Define system properties and constraints e.g. reliability, response time and storage occupancy,
Security, etc.. Alternatively they may define platform constraints like, I/O devices capability, data
representations. Process requirements may also be specified mandating a particular CASE system,
programming language or development method. These requirements arise through organizational
policies, budget limits, interoperability needs etc. They may be considered to be more critical than
functional requirements because if these are not met, the system will be useless.
Non-functional requirements can be further classified as shown in Fig 12

Fig 12: Classification of Non-functional requirements

The classification can be described as given below:
1. Product requirements: Requirements which specify that the delivered product must behave in a
particular way e.g. execution speed, reliability, etc.
2. Organizational requirements: Requirements which are a consequence of organizational policies
and procedures e.g. process standards used, implementation requirements, etc.
3. External requirements: Requirements which arise from factors which are external to the system
and its development process e.g. interoperability requirements, legislative requirements, etc.
Non-functional requirements may affect the overall architecture of a system rather than the
individual components. For example, to ensure that performance requirements are met, you may
have to organize the system to minimize communications between components.
A single non-functional requirement, such as a security requirement, may generate a number of
related functional requirements that define system services that are required. It may also generate
requirements that restrict existing requirements.

Metrics for specifying nonfunctional requirements

Since non-functional requirements are equally important for the operation of a software metrics
have been defined to indicate non-functional requirements as a part of requirements specification
document. This is indicated in Table 1.
Table 1 : Metrics for non-functional requirements

Property Measure

Speed Processed transactions/second

User/event response time
Screen refresh time
Size Mbytes
Number of ROM 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

Requirements engineering processes

Requirements engineering involves three key activities. These are discovering requirements by
interacting with stakeholders (elicitation and analysis); converting these requirements into a
standard form (specification); and checking that the requirements actually define the system that
the customer wants (validation).

The output of the RE process is a system requirements document. The amount of time and effort
devoted to each activity in an iteration depends on the stage of the overall process, the type of
system being developed, and the budget that is available.
 Requirements elicitation

The aims of the requirements elicitation process are to understand the work that stakeholders do
and how they might use a new system to help support that work. During requirements elicitation,
software engineers work with stakeholders to find out about the application domain, work
activities, the services and system features that stakeholders want, the required performance of the
system, hardware constraints, and so on.

Eliciting and understanding requirements from system stakeholders is a difficult process for
several reasons:
1. Stakeholders often don’t know what they want from a computer system except in the most
general terms; they may find it difficult to articulate what they want the system to do; they may
feasibility
make unrealistic demands because they don’t know what is and isn’t feasible
 2. Stakeholders in a system naturally express requirements in their own terms and with implicit
knowledge of their own work. Requirements engineers, without experience in the customer’s
requirements
domain, may not understand these requirements.
understanding
3. Different stakeholders, with diverse requirements, may express their requirements in different

requirement ways. Requirements engineers have to discover all potential sources of requirements and discover
expression commonalities and conflict.

4. Political factors may influence the requirements of a system. Managers may demand specific
political
system requirements because these will allow them to increase their influence in the organization.
factors

5. The economic and business environment in which the analysis takes place is dynamic. It

new inevitably changes during the analysis process. The importance of particular requirements may
requirements change. New requirements may emerge from new stakeholders who were not originally consulted.

A process model of the elicitation and analysis process is shown in Figure 4.7

The requirements elicitation and analysis process

The process activities are:

1. Requirements discovery and understanding This is the process of interacting with
 stakeholders of the system to discover their requirements. Domain requirements from
stakeholders and documentation are also discovered during this activity.

2. Requirements classification and organization This activity takes the unstructured

collection of requirements, groups related requirements and organizes them into coherent
clusters.

3. Requirements prioritization and negotiation Inevitably, when multiple stakeholders are

involved, requirements will conflict. This activity is concerned with prioritizing
requirements and finding and resolving requirements conflicts through negotiation.
Usually, stakeholders have to meet to resolve differences and agree on compromise
requirements.

4. Requirements documentation The requirements are documented and input into the next
round of the spiral. An early draft of the software requirements documents may be
produced at this stage, or the requirements may simply be maintained informally on
whiteboards, wikis, or other shared spaces.

Requirements elicitation techniques

Requirements elicitation involves meeting with stakeholders of different kinds to discover

information about the proposed system.
There are two fundamental approaches to requirements elicitation:

1. Interviewing, where you talk to people about what they do.

2. Observation or ethnography, where you watch people doing their job to see what artifacts they
use, how they use them, and so on.

Interviewing
Formal or informal interviews with system stakeholders are part of most requirements engineering
processes. In these interviews, the requirements engineering team puts questions to stakeholders
about the system that they currently use and the system to be developed. Requirements are derived
from the answers to these questions.
Interviews may be of two types:
1. Closed interviews, where the stakeholder answers a predefined set of questions.
2. Open interviews, in which there is no predefined agenda. The requirements engineering team
explores a range of issues with system stakeholders and hence develops a better understanding of
their needs.

In practice, interviews with stakeholders are normally a mixture of both of these. You may have
to obtain the answer to certain questions, but these usually lead to other issues that are discussed
in a less structured way. Completely open-ended discussions rarely work well.

Interviews are good for getting an overall understanding of what stakeholders do, how they might
interact with the new system, and the difficulties that they face with current systems. People like
talking about their work, and so they are usually happy to get involved in interviews.

Eliciting domain knowledge through interviews can be difficult, for two reasons:

1. All application specialists use jargon specific to their area of work. It is impossible for them to
discuss domain requirements without using this terminology. They normally use words in a precise
and subtle way that requirements engineers may misunderstand.

2. Some domain knowledge is so familiar to stakeholders that they either find it difficult to explain
or they think it is so fundamental that it isn’t worth mentioning.

To be an effective interviewer, you should bear two things in mind:

1. You should be open-minded, avoid preconceived ideas about the requirements, and willing to
listen to stakeholders. If the stakeholder comes up with surprising requirements, then you should
be willing to change your mind about the system.
2. You should prompt the interviewee to get discussions going by using a springboard question or
a requirements proposal, or by working together on a prototype system.

Ethnography

Ethnography is an observational technique that can be used to understand operational processes

and help derive requirements for software to support these processes.

Ethnography is particularly effective for discovering two types of requirements

1. Requirements derived from the way in which people actually work, rather than the way in which
business process definitions say they ought to work. In practice, people never follow formal
processes. For example, air traffic controllers may switch off a conflict alert system that detects
aircraft with intersecting flight paths, even though normal control procedures specify that it should
be used. The conflict alert system is sensitive and issues audible warnings even when planes are
far apart. Controllers may find these distracting and prefer to use other strategies to ensure that
planes are not on conflicting flight paths.

2. Requirements derived from cooperation and awareness of other people’s activities. For example,
air traffic controllers (ATCs) may use an awareness of other controllers’ work to predict the
number of aircraft that will be entering their control sector. They then modify their control
strategies depending on that predicted workload. Therefore, an automated ATC system should
allow controllers in a sector to have some visibility of the work in adjacent sectors.

Ethnography can be combined with the development of a system prototype

Ethnography is helpful to understand existing systems, but this understanding does not always help
with innovation. Innovation is particularly relevant for new product development. Ethnographic
studies can reveal critical process details that are often missed by other requirements elicitation
techniques. However, because of its focus on the end user, this approach is not effective for
discovering broader organizational or domain requirements or for suggestion innovations.
Stories and scenarios
Stories and scenarios are ways of capturing information. You can then use these when
interviewing groups of stakeholders to discuss the system with other stakeholders and to
develop more specific system requirements.

The advantage of stories is that everyone can easily relate to them. We found this approach to
be particularly useful to get information from a wider community than we could realistically
interview.

A scenario starts with an outline of the interaction. During the elicitation process, details are
added to create a complete description of that interaction. At its most general, a scenario may
include:
1. A description of what the system and users expect when the scenario starts.
2. A description of the normal flow of events in the scenario.
3. A description of what can go wrong and how resulting problems can be handled.
4. Information about other activities that might be going on at the same time.
5. A description of the system state when the scenario ends.

Requirements specification

 Requirements specification is the process of writing down the user and system
requirements in a requirements document.
 Ideally, the user and system requirements should be clear, unambiguous, easy to
understand, complete, and consistent.
 In practice, this is almost impossible to achieve.
 Stakeholders interpret the requirements in different ways, and there are often inherent
conflicts and inconsistencies in the requirements.

 User requirements are almost always written in natural language supplemented by

appropriate diagrams and tables in the requirements document.
 System requirements may also be written in natural language, but other notations based
on forms, graphical, or mathematical system models can also be used.
 Figure 4.11 summarizes possible notations for writing system requirements.
Natural language specification

 Natural language has been used to write requirements for software since the 1950s.
 It is expressive, intuitive, and universal.
 It is also potentially vague and ambiguous, and its interpretation depends on the
background of the reader.

To minimize misunderstandings when writing natural language requirements, it is recommend

that you follow these simple guidelines:

1. Invent a standard format and ensure that all requirement definitions adhere to that format.
Standardizing the format makes omissions less likely and requirements easier to check.
2. Use language consistently to distinguish between mandatory and desirable requirements.
Mandatory requirements are requirements that the system must support and are usually written
using “shall.” Desirable requirements are not essential and are written using “should.”
3. Use text highlighting (bold, italic, or color) to pick out key parts of the requirement.
4. Do not assume that readers understand technical, software engineering language. It is easy
for words such as “architecture” and “module” to be misunderstood.
5. Whenever possible, you should try to associate a rationale with each user requirement. The
rationale should explain why the requirement has been included and who proposed the
requirement (the requirement source), so that you know whom to consult if the requirement
has to be changed.

Structured specifications
 Structured natural language is a way of writing system requirements where
requirements are written in a standard way rather than as free-form text.
 This approach maintains most of the expressiveness and understandability of natural
language but ensures that some uniformity is imposed on the specification.
 Structured language notations use templates to specify system requirements.
 The specification may use programming language constructs to show alternatives and
iteration, and may highlight key elements using shading or different fonts.

To use a structured approach to specifying system requirements, you define one or more
standard templates for requirements and represent these templates as structured forms.

When a standard format is used for specifying functional requirements, the following
information should be included:
1. A description of the function or entity being specified.
2. A description of its inputs and the origin of these inputs.
3. A description of its outputs and the destination of these outputs.
4. Information about the information needed for the computation or other entities in the system
that are required (the “requires” part).
5. A description of the action to be taken.
6. If a functional approach is used, a precondition setting out what must be true before the
function is called, and a postcondition specifying what is true after the function is called.
7. A description of the side effects (if any) of the operation.
 The structured specification of a requirement for an insulin pump

Use cases
 Use cases are a way of describing interactions between users and a system using a
graphical model and structured text.
 In their simplest form, a use case identifies the actors involved in an interaction and
names the type of interaction.
 You then add additional information describing the interaction with the system.
 The additional information may be a textual description or one or more graphical
models such as the UML sequence or state charts
 Use cases are documented using a high-level use case diagram.
 The set of use cases represents all of the possible interactions that will be described in
the system requirements.
 Actors in the process, who may be human or other systems, are represented as stick
figures. Each class of interaction is represented as a named ellipse.
 Lines link the actors with the interaction.

The software requirements document

 The software requirements document (sometimes called the software requirements
specification or SRS) is an official statement of what the system developers should
implement.
 It may include both the user requirements for a system and a detailed specification of
the system requirements. Sometimes the user and system requirements are integrated
into a single description.
 In other circumstances, such as software product or business system development, a
detailed requirements document may not be needed.
The requirements document has a diverse set of users, ranging from the senior management of
the organization that is paying for the system to the engineers responsible for developing the
software.

Requirements validation
 Requirements validation is the process of checking that requirements define the system
that the customer really wants.
 It overlaps with elicitation and analysis, as it is concerned with finding problems with
the requirements.
 Requirements validation is critically important because errors in a requirements
document can lead to extensive rework costs when these problems are discovered
 during development or after the system is in service.

During the requirements validation process, different types of checks should be carried out on
the requirements in the requirements document. These checks include:
1. Validity checks These check that the requirements reflect the real needs of system users.
Because of changing circumstances, the user requirements may have changed since they were
originally elicited.
2. Consistency checks Requirements in the document should not conflict. That is, there should
not be contradictory constraints or different descriptions of the same system function.
3. Completeness checks The requirements document should include requirements that define
all functions and the constraints intended by the system user.
4. Realism checks By using knowledge of existing technologies, the requirements should be
checked to ensure that they can be implemented within the proposed budget for the system.
These checks should also take account of the budget and schedule for the system development.
5. Verifiability To reduce the potential for dispute between customer and contractor, system
requirements should always be written so that they are verifiable. This means that you should
be able to write a set of tests that can demonstrate that the delivered system meets each specified
requirement.

A number of requirements validation techniques can be used individually or in conjunction

with one another:
1. Requirements reviews The requirements are analyzed systematically by a team of reviewers
who check for errors and inconsistencies.
2. Prototyping This involves developing an executable model of a system and using this with
end-users and customers to see if it meets their needs and expectations. Stakeholders
experiment with the system and feed back requirements changes to the development team.
3. Test-case generation Requirements should be testable. If the tests for the requirements are
devised as part of the validation process, this often reveals requirements problems. If a test is
difficult or impossible to design, this usually means that the requirements will be difficult to
implement and should be reconsidered.

Requirements change
 The requirements for large software systems are always changing.
 One reason for the frequent changes is that these systems are often developed to address
“wicked” problems—problems that cannot be completely defined.
 Because the problem cannot be fully defined, the software requirements are bound to
 be incomplete.
 During the software development process, the stakeholders’ understanding of the
problem is constantly changing (Figure 4.18).
 The system requirements must then evolve to reflect this changed problem
understanding

Most changes to system requirements arise because of changes to the business environment of
the system:
1. The business and technical environment of the system always changes after installation. New
hardware may be introduced and existing hardware updated. It may be necessary to interface
the system with other systems. Business priorities may change (with consequent changes in the
system support required), and new legislation and regulations may be introduced that require
system compliance.
2. The people who pay for a system and the users of that system are rarely the same people.
System customers impose requirements because of organizational and budgetary constraints.
These may conflict with end-user requirements, and, after delivery, new features may have to
be added for user support if the system is to meet its goals.
3. Large systems usually have a diverse stakeholder community, with stakeholders having
different requirements. Their priorities may be conflicting or contradictory. The final system
requirements are inevitably a compromise, and some stakeholders have to be given priority.
With experience, it is often discovered that the balance of support given to different
stakeholders has to be changed and the requirements re-prioritized.

Requirements management planning

Requirements management planning is concerned with establishing how a set of evolving
requirements will be managed. During the planning stage, you have to decide on a number of
issues:
1. Requirements identification Each requirement must be uniquely identified so that it can be
cross-referenced with other requirements and used in traceability assessments.
2. A change management process This is the set of activities that assess the impact and cost of
changes. I discuss this process in more detail in the following section.
3. Traceability policies These policies define the relationships between each requirement and
between the requirements and the system design that should be recorded. The traceability
policy should also define how these records should be maintained.
4. Tool support Requirements management involves the processing of large amounts of
information about the requirements. Tools that may be used range from specialist requirements
management systems to shared spreadsheets and simple database systems.

Requirements management needs automated support, and the software tools for this should be
chosen during the planning phase. You need tool support for:
1. Requirements storage The requirements should be maintained in a secure, managed data
store that is accessible to everyone involved in the requirements engineering process.
2. Change management The process of change management (Figure 4.19) is simplified if active
tool support is available. Tools can keep track of suggested changes and responses to these
suggestions.
3. Traceability management As discussed above, tool support for traceability allows related
requirements to be discovered. Some tools are available which use natural language processing
techniques to help discover possible relationships between requirements.

Requirements change management

Requirements change management (Figure 4.19) should be applied to all proposed changes to
a system’s requirements after the requirements document has been approved. Change
management is essential because you need to decide if the benefits of implementing new
requirements are justified by the costs of implementation.

There are three principal stages to a change management process:

1. Problem analysis and change specification The process starts with an identified
requirements problem or, sometimes, with a specific change proposal. During this stage, the
problem or the change proposal is analyzed to check that it is valid. This analysis is fed back
to the change requestor who may respond with a more specific requirements change proposal,
or decide to withdraw the request.
2. Change analysis and costing The effect of the proposed change is assessed using traceability
information and general knowledge of the system requirements. The cost of making the change
is estimated in terms of modifications to the requirements document and, if appropriate, to the
system design and implementation. Once this analysis is completed, a decision is made as to
whether or not to proceed with the requirements change.
3. Change implementation The requirements document and, where necessary, the system
design and implementation, are modified. You should organize the requirements document so
that you can make changes to it without extensive rewriting or reorganization. As with
programs, changeability in documents is achieved by minimizing external references and
making the document sections as modular as possible.