resolved throughout the process.

Spiral model has been very influential in helping people

think about iteration in software processes and introducing the risk-driven approach to
development. In practice, however, the model is rarely used as published for practical
software development.
Sectors of spiral model
The following are the sectors of the spiral model:
1. Objective setting -Specific objectives for the phase are identified.
2. Risk assessment and reduction-Risks are assessed and activities put in place to
reduce the key risks.
3. Development and validation-A development model for the system is chosen
which can be any of the generic models.
4. Planning-The project is reviewed and the next phase of the spiral is planned.

Requirements Engineering

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 categorised 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

18
 2. Systems Requirements are a structured document setting out detailed descriptions
of the system‟s 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

19
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.

20
 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

21
 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. Organisational requirements: Requirements which are a consequence of
organisational 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.

22
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

The software requirements document

The software requirements document is the official statement of what is required of the
system developers. It should include both a definition of user requirements and a
specification of the system requirements. It is not a design document. As far as possible,
it should be a set of what the system should do rather than how it should do it.
Fig 13 shows the users of a requirements document. The illustration is self-explanatory. It
should be noted that requirements specification is not just for end users or for developers.
It is for all those entities who are involved through out the software development process.

23
 Fig 13: Users of a software requirements document

IEEE structure of a requirements document

The table below describes the various chapters and its description for a standard
requirements document. This is given by the IEEE. All software do not necessarily
follow this exact structure. But a standard structure tuned to the needs of the application
is required to be followed.

24
 Table 2: The IEEE structure of a requirements document
Chapter Description

Preface This should define the expected readership of the document and describe
its version history, including a rationale for the creation of a new version
and a summary of the changes made in each version.
Introduction This should describe the need for the system. It should briefly describe
the system‟s functions and explain how it will work with other systems.
It should also describe how the system fits into the overall business or
strategic objectives of the organization commissioning the software.
Glossary This should define the technical terms used in the document. You should
not make assumptions about the experience or expertise of the reader.
User requirements Here, you describe the services provided for the user. The nonfunctional
definition system requirements should also be described in this section. This
description may use natural language, diagrams, or other notations that
are understandable to customers. Product and process standards that
must be followed should be specified.
System architecture This chapter should present a high-level overview of the anticipated
system architecture, showing the distribution of functions across system
modules. Architectural components that are reused should be
highlighted.
System requirements This should describe the functional and nonfunctional requirements in
specification more detail. If necessary, further detail may also be added to the
nonfunctional requirements. Interfaces to other systems may be defined.
System models This might include graphical system models showing the relationships
between the system components and the system and its environment.
Examples of possible models are object models, data-flow models, or
semantic data models.
System evolution This should describe the fundamental assumptions on which the system
is based, and any anticipated changes due to hardware evolution,
changing user needs, and so on. This section is useful for system
designers as it may help them avoid design decisions that would
constrain likely future changes to the system.
Appendices These should provide detailed, specific information that is related to the
application being developed; for example, hardware and database
descriptions. Hardware requirements define the minimal and optimal
configurations for the system. Database requirements define the logical
organization of the data used by the system and the relationships
between data.

25
Index Several indexes to the document may be included. As well as a normal
alphabetic index, there may be an index of diagrams, an index of
functions, and so on.

Ways of writing system requirements specification

There are different ways of writing requirements specification. Table 3 describes the
notations generally used and its description:

Table 3: Notations for writing requirement specification

Notation Description

Natural The requirements are written using numbered sentences in

language natural language. Each sentence should express one
requirement.
Structured The requirements are written in natural language on a standard
natural form or template. Each field provides information about an
language aspect of the requirement.
Design This approach uses a language like a programming language,
description but with more abstract features to specify the requirements by
languages defining an operational model of the system. This approach is
now rarely used although it can be useful for interface
specifications.
Graphical Graphical models, supplemented by text annotations, are used to
notations define the functional requirements for the system; UML use
case and sequence diagrams are commonly used.
Mathematical These notations are based on mathematical concepts such as
specifications finite-state machines or sets. Although these unambiguous
specifications can reduce the ambiguity in a requirements
document, most customers don‟t understand a formal
specification. They cannot check that it represents what they
want and are reluctant to accept it as a system contract

Tools for Specifying System Requirements

This section deals with the ways to write requirements specification.
1. Structured language: A language with constructs similar to programming
Example: System Requirements for Address book

26
Case : 1
List Option selected
Show first 3 addresses
If down arrow pressed
scroll the addresses
else
If any “Alpha key pressed
Display the first address starting from that alpha
End if
Endif
2. Form Based approach: Creates a standard format for specifying requirements.
Typically can have entries like :
1. Definition of the function or entity.
2. Description of inputs and where they come from.
3. Description of outputs and where they go to.
4. Indication of other entities required.
5. Pre and post conditions (if appropriate )
This method eliminates problems of natural language. This also brings in uniformity &
comprehensiveness. Not always useful Example specifying interactions)
3. Tabular Model
This is also used to supplement natural language. This is particularly useful when
you have to define a number of possible alternative courses of action. Example:

Condition Action
Sugar level falling (r2 < r1) CompDose = 0
Sugar level stable (r2 = r1) CompDose = 0
Sugar level increasing and rate of CompDose = 0
increase decreasing ((r2-r1)<(r1-r0))
Sugar level increasing and rate of CompDose = round ((r2-r1)/4)
increase stable or increasing. ((r2-r1) ≥ If rounded result = 0 then
(r1-r0)) CompDose = MinimumDose
4. Graphical Model ( like sequence diagram of UML)
This is most useful when state changes need to be depicted OR Sequence of actions &
interactions need to be described.

27
Sample Requirements Document
A typical SRS would look like the following example taken from a weblink free to
download document.
To be strictly used for Educational purpose only:
A document of Global Digital Megacorp Student Information Management System
available on:
web.uvic.ca/~cloke/Seng321Designer/SENG321-2008_Group4_RS1.0.doc
Requirements Engineering (RE) processes
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 which are:
1. Feasibility Study
2. Requirements elicitation;
3. Requirements analysis;
4. Requirements validation;
5. Requirements management.
In practice, RE is an iterative activity in which these processes are interleaved.
The spiral view of requirements engineering process is shown in Fig 14

28
 Fig 14: Spiral view of Requirements engineering process
1. Feasibility Study : Decides whether or not the proposed system is worthwhile
attempting. A short focused study that checks the following:
a) If the system contributes to organisational objectives;
b) If the system can be engineered using current technology and within
budget;
c) If the system can be integrated with other systems that are used
d) If the system can fit into the cultural framework of the organizational
culture and acceptable to all the stake-holders
Information collection is done by asking questions to the stake-holders of the system
Typical Questions could be:
a) What if the system wasn‟t implemented?
b) What are current process problems?
c) How will the proposed system help?
d) What will be the integration problems?

29
 e) Is new technology needed? What skills?
f) What facilities must be supported by the proposed system?
2. Requirement Elicitation
Involves Interacting with 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. This may involve stakeholders like end-users, managers,
Engineers involved in maintenance, domain experts, trade unions, etc. Domain
requirements are also discovered at this stage.
Domain Requirements are derived from the application domain rather than specific needs
of a customer in that domain. They usually refer to specialized domain terminology /
concepts. They describe system characteristics & features that reflect the domain.
Domain requirements could be
1. New functional requirements,
2. Constraints on existing requirements or
3. Define specific computations.
If domain requirements are not satisfied, the system may be unworkable.
The requirements elicitation and analysis process
Fig 15 shows the process of requirements elicitation and analysis.

Fig 15: Requirements elicitation and analysis process

30
Requirements Elicitation is done through
1. Interviewing: The RE team puts questions to stakeholders about the system that
they use and the system to be developed. There are two types of interviews:
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 is good for getting an
overall understanding of what stakeholders do & how they interact with the
system. This method is not good for understanding domain requirements
2. Observation & study: Observation (in-situ): The RE team observes the manual
process in action, in-situ and infers required information. This is good for process
oriented systems. Minimal disturbance to user staff.
Study- Additional information is gathered from study of documents, forms
manuals , rulebooks and other artifacts used by the actors of the system . Here the
analyst must be well experienced with the domain
Problems with Requirement Elicitation
1. Stakeholders don‟t know what they really want.
2. Stakeholders express requirements in their own terms.
3. Different stakeholders may have conflicting requirements.
4. Organisational and political factors may influence the system requirements.
5. The requirements change during the analysis process
6. New stakeholders may emerge and the business environment change
Activities of Requirement Analysis
1. Requirements classification and organisation : Grouping related requirements and
organising them into coherent clusters
2. Prioritisation and negotiation: Prioritising requirements and resolving
requirements conflicts requirements documentation
3. Requirements are documented and input into the next round of the spiral

31
Requirements validation
This is 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.
Requirements checking
To check the requirements for a software, the following parameters need to be
considered:
1. Validity. Does the system provide the functions which best support the customer‟s
needs?
2. Consistency. Are there any requirements conflicts?
3. Completeness. Are all functions required by the customer included?
4. Realism. Can the requirements be implemented given available budget and
technology
5. Verifiability. Can the requirements be checked?
Requirements validation techniques
Various ways exist for validating the requirements:
1. Requirements reviews: This involves systematic manual analysis of the
requirements.
2. Prototyping: This involves using an executable model of the system to check
requirements.
3. Test-case generation: Developing tests for requirements to check testability.
Requirements reviews
It is essential that 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.
Review checks
Parameters for review checks consist of checking for the following:
1. Verifiability: Is the requirement realistically testable?
2. Comprehensibility: Is the requirement properly understood?
3. Traceability: Is the origin of the requirement clearly stated?

32
 4. Adaptability: Can the requirement be changed without a large impact on other
requirements?
Requirements management
Process of understanding and controlling the changing requirements during the
requirements engineering process and system development forms the major activity of
requirements management. Requirements are inevitably incomplete & 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. All this needs reconciliation &
management.
Reasons for change in Requirements
1. The business and technical environment of the system always changes after
installation. New hardware may be introduced, 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 the system must necessarily abide by.
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 user community, with many users having
different requirements and priorities that may be conflicting or contradictory. The
final system requirements are inevitably a compromise between them and, with
experience, it is often discovered that the balance of support given to different
users has to be changed.
Requirements management planning
This activity establishes the level of requirements management detail that is required. It is
essential that Requirements management decisions need to be taken for the following
purposes:
1. Requirements identification- Each requirement must be uniquely identified so that
it can be cross-referenced with other requirements.

33
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.
4. Tool support- Tools that may be used range from specialist requirements
management systems to spreadsheets and simple database systems.

34