SRE Complete Chapters

Chapter # 03: Requirements Analysis
CHAPTER # 01
REQUIREMENTS ENGINEERING AN INTRODUCTION
1.1: - Requirements
Requirements is the phase where the “what “of the software system is define. It involves extensive user
participation and ends with an approved set of requirements documented in a software requirements
specifications (SRS) document. These software requirements specifications (SRS) form the basis of all further
work in the project.
Requirements are defined during the early stages of a system development as a specification of what should be
implemented or as a constraint of some kind on the system.
Before we can design the software for the hardware that we also have to "design", we must know what that
software + hardware, i.e the machine, shall do. Expression of that `what' is that which we call `the
requirements'.
IEEE standard 610.12-1990 defines requirements in the context of a software project as follows:
1) A condition or capability needed by a user to solve a problem or achieve an objective.
2) A condition or capability that must be met or possessed by a system or system component to satisfy a
contract, standard, specification or other formally imposed documents.
Requirements focuses on “What” to build rather than “How” to build. We produce the requirements or u can
say we gather the requirements to communicate with the : Stake Holders, Development Team, Documenters,
etc.
Requirements are a make or break phase of the software development process. If the requirements are carefully
chosen to represent what the customer wants, needs, and expects, then the project has a good chance of success.
If not, the project may very well be doomed.
Characteristics Of Requirements: - Requirements must be validated
 Are the requirements correct?
1
 Are the requirements consistent?

 Are the requirements complete?
 Are the requirements realistic?
 Does each requirement describe something needed by the customer?
 Are the requirements verifiable?
 Are the requirements traceable?
1.1.1: - Software Requirements: -
“Any function, constraint, or other property that must be provided, met, or satisfied to fulfill the need of the
system’s intended user”
The software requirements can be categorized in various levels of abstraction, importance, scope, exactitude,
and level of details. For example:
 Very general requirements which set out in broad terms what the system should do.
 Functional requirements which define part of the systems functionality.
 Non-functional requirements that put constraints on the system developed:
 Implementation requirements which state how the system must be implemented.
 Performance requirements which specify a minimum acceptable performance for the system.
 Usability requirements which specify the maximum acceptable time to demonstrate the use of
the system.
So here the more focuses is on the functional and non-functional requirements. Functional requirements focus
on the “What” of the system and identify the “functions” and “data” related requirements. Non-functional
requirements focus on the “How well” aspects of the system and identify attributes like “performance”,
”maintainability”, “scalability”, “inter-operability”, “reliability”, “portability” and the “constraints” under
which the system needs to operate.
Often, persons gathering requirements focus on functional requirements. Non-functional requirements are
typically missed out because most commonly used requirements analysis methodologies (structured analysis,
object oriented analysis) focus on the representation of functional requirements. Users may never accepts
systems that meet all the functional requirements but ignore some important non-functional requirements.
2
1.2: - Requirements Engineering: An Overview
Requirements engineering provides the appropriate mechanism for understanding what the customer wants,
analyzing need, assessing feasibility, negotiating a reasonable solution, specifying the solution unambiguously,
validating the specifications and managing the requirements as they are transformed into an operational system.
The use of the term ‘engineering’ implies that systematic and repeatable techniques should be used to ensure
that system requirements are complete, consistent, relevant, etc
The author quotes the definition of Requirements Engineering from Pohl (1993) "Requirements Engineering
can be defined as the systematic process of developing requirements through an iterative co-operative process
of analyzing the problem, documenting the resulting observations in a variety of representation formats, and
checking the accuracy of the understanding gained."
Requirements engineering (RE) is generally accepted to be the most critical and complex process within the
development of embedded systems.
 RE has the most dominant impact on what the resulting product is capable of and is not capable of.
 RE is the process in which the most diverse set of product demands from the most diverse set of
stakeholders is being considered.
Requirements engineering can be divided into two main set of activities:
1) Requirements Definition
2) Requirements Management
3
Requirements Definition consists of:
1) Requirements Elicitation or gathering of requirements.

2) Requirements Analysis or Modeling: - Requirements that are gathered are modeled and analyzed using
modeling tools such as dataflow diagrams, object oriented modeling techniques, entity relationship diagrams,
etc.
3) Requirements Documentation: - Here the requirements that are gathered and modeled are put together in
a document, typically known as the software requirements specification (SRS).
4) Requirements Review: - This consists of review of SRS by all stakeholders. The reviewed and approved
SRS forms the basis for the work products to be created in the later parts of the software life cycle.
Requirements Management consists of:
1) Requirements Change Management: - This involves systematic handling of changes to agreed

requirements (SRS) during the course of the project.
4
2) Requirements Traceability: - This consist of maintaining traceability between the agreed (and changed)
SRS and the other work products (like design documents, test plans) created down stream in the software life
cycle.
1.3 : Importance Of Requirements Engineering: -
How can we ensure that we have specified a system that properly meets the customer needs and satisfies the
customers expectations. There is no fool proof answer to this difficult question but a solid requirements
engineering process is the best solution we currently have.
Requirements form the backbone of any successful project, setting the scope for all subsequent work and
providing the measure of success or failure. User requirements define stakeholders' needs whilst the system
requirements define the functional and non-functional aspects of the system that will realize this need. If these
requirements are wrong or misinterpreted there will be confusion, the product will not meet the customers'
expectations and the increasing costs could result in the project failing[1]. With 70% of project costs committed
before full scale development starts[2], it is easy to see why the costs of correcting mistakes after production
can be 100 times the cost of getting the requirements right.
Suppose we have gathered the wrong requirements now what happens if we did that?
 The system may be delivered late and cost more than originally expected.
 The customer and end-users are not satisfied with the system. They may not use its facilities or may
even decide to scrap it altogether.
 The system may be unreliable in use with regular system errors and crashes disrupting normal operation.
 If the system continues in use, the costs of maintaining and evolving the system are very high.
So to gather the right requirements from the customer and to ignore the above losses there will be need of
requirements engineering process which actually defines the appropriate way of gathering the requirements to
write the specifications.
As we know that the requirements engineering is the systematic process of developing the right requirements.
Whose importance can also be determine by answering the following questions
5
 How can the process be systematic when there are many unknown factors at the beginning of the process?
 How can we take a step-by-step approach when we don’t know how many steps will be needed or when it
is unclear that the end is reached?
1.4 : Requirements Engineering Process: -
Traditionally, RE is performed in the beginning of the system development lifecycle. However, in large and
complex systems development, developing an accurate set of requirements that would remain stable throughout
the development has been realized to be impossible in practice. RE is an incremental and iterative process,
performed in parallel with other system development activities such as design, and going into more detail in
each iteration. RE activities cover the entire system and software development lifecycle.
Stakeholder Needs
Inputs: -
 Existing System Information: - Information about systems that either will be replaced by the proposed
system, or which the system must interact with.
 Stakeholder Needs: - Descriptions of needs stakeholders perceived to have of the suggested system.
 Domain Information: - General information about the nature of the domain and the types of activities
that are covered by the situation being considered.
6
Controls: -
 Organizational Standards: - Standards used in the organization to coordinate system development or
maintain quality, etc.
 Regulations: - External regulations that need to be considered as the problem is considered and the
solution evolves.
Mechanisms: -
 Stakeholders: - Are people or organizations affected by the system and who have a direct influence on
the requirements? End-users, managers, engineers who develop or maintain related systems, domain experts,
union representatives, etc.
 May not know what they really want, or may find it difficult to articulate
 May make unrealistic demands
 Express requirements in their own terms with implicit knowledge of their own work
 May be politically motivated
 Analyst: - The member of the project team responsible for managing the requirements process
(requirements manager).
Outputs: -
Requirements: - The agreed upon functional and non-functional requirements for the system.
System Specification: - A more detailed version of the system which may be required in some instances.
System Models: - Models, usually in diagrammatic form, which describe the system from the necessary
perspectives.
RE processes can be improved by the systematic introduction of good requirements engineering practice. Each
improvement cycle identifies good practice guidelines and works to introduce them in an organization.
1.5 : Spiral Model of Requirements Engineering Process: -
7
The spiral model of requirements engineering processes emphasis on continuous reassessment of the elicitation
and analysis and combines the iterative and sequential approaches. Here a number of task regions are defined
and these task regions are traversed in each iteration. The spiral nature of the model emphasizes that the
successive iteration result in a more completely engineered product. As this evolutionary process begins the
software engineering team moves around the spiral in a clockwise direction beginning at the center.
The spiral model of requirements engineering is divided into four number of framework activities, also called
task regions which are:
Requirements Elicitation ------- task required to gather the requirements and after the completion of this task
region we get the informal statements of the requirements.
8
Analysis and negotiation -------- task required to analyzed and model the gathered requirements. Analysis
categorizes requirements and organizes them into related subsets, explores each requirement in relationship to
others and ranks the requirements based on the needs of the customers / users. At the end of this task region the
requirements will be agreed for the further task.
Requirements documentation -------- task required to document the gathered and modeled requirements at the
end of this task we get the software requirements specification (SRS).
Requirements validation -------- task required to examine the specification to ensure that all system
requirements have been stated unambiguously. Or simple the task required to validate the requirements. At the
end of this task region we will get the final requirements document and validation report.
Using the spiral model software is developed in a series of incremental releases. During early iterations the
incremental release might be a paper model or prototype. During later iterations increasingly more complete
versions of the engineered system are produced.
1.6 : RE Process Maturity Model: -
The CMM is focused on management of software development and does not cover the requirements
engineering process, so we have created a comparable model of requirements engineering process that model is
known as RE process maturity mode.
It will use appropriate methods and techniques for RE, will have defined standarts for requirements documents,
requirements description etc. May use automated tools to support process activities and it will have
management policies to ensure that process is followed. It may use process measurements to asses the value of
process changes...
REMM is a three level model.
9
RE process maturity model will:
 defined standards for requirements documents

 defined standards for requirement descriptions
 use automated tools to support process activities
 management policies and procedures
Level-1---Initial-level
Level 1 organizations do not have a defined requirements engineering process and often suffer from the
problems discussed above. They do not use advanced methods to support their requirements engineering
processes. They often fail to produce good quality requirement documents on time and within budget. They are
dependent on the skills and experience of individual engineers for requirements elicitation, analysis and
validation.
Level-2-—Repeatable-level
Level 2 organizations have defined standards for requirements documents and requirements descriptions and
have introduced policies and procedures for requirements management. They may use some advanced tools and
techniques in their requirements engineering processes. Their requirements documents are more likely to be of a
consistently high quality and to be produced on schedule.
Level-3---Defined-level
Level 3 organizations have a defined requirement engineering process model based on good practices and
10
techniques. They have an active process improvement programmed in place and can make objectives
assessments of the value of new methods and techniques.
1.7 : Requirements Engineering Life Cycle: -
The requirements engineering life cycle basically consists of three main activities, which are :
1) Feasibility study
2) Elicitation and Analysis -------- this process activity further consists of sub activities which are:
 Requirements Specifications
 User and system requirements
 Requirements documentation
3) Validation
Feasibility Study
Feasibility study decides whether or not the proposed system is worthwhile.It is a short focused study, which
aims to answer questions like, is the Overall Objective satisfied? , Can the system be implemented given the
current technology and cost factors? , And can this system be integrated with other systems that are already in
place?.
11
Elicitation And Analysis
This phase is concerned with understanding the application domain, what services the system should provide,
the required performance of the system, hardware constraints and so on. That’s why this activity Some times
called requirements discovery.
The Process activities in this phase are:
Domain Understanding ------ The main processes involved in this stage are
 Work Flow Study
 Identifying the various stakeholders
 Defining the boundary and constraints of the solution
Requirements Collection ----- The steps involved in this stage are
 Understanding the RFP
 Conducting Interviews and Questionnaire with the customer
 Workshops/Brain Storming Sessions
 Analysis
Classification --------- Using more Use-Case examples to classify the requirements accordingly. Unstructured
requirements are organized.
Conflict Resolution ------- This is the activity of finding and resolving conflicting requirements
Prioritization --------- The set of important requirements are discovered through interaction with the
stakeholders and ordered
Requirements Checking ------ They are checked for completeness and consistency
At the end of this activity we will get the complete preliminary requirements specifications.
Refinement
This phase is concerned with showing that the requirements actually define the system that the customer wants.
It is concerned with finding problems with the requirements. This stage is important because the errors found
here could prevent extensive rework costs when they are subsequently found during development or after the
system is in service.
The various types of checks that are done during this activity are:
12
 Validity Checks
 Consistency Checks
 Completeness Checks
 Realism Checks
 Verifiability
The various checks were performed for the requirements collected. Certain techniques used are simulations,
modeling and component decomposition. Conflicting requirements are resolved. Baseline requirements are
specified. At the end of this activity we will get the Refined, Verified and Validated Specification of
Requirements.
1.8 Summary
Requirements are defined during the early stages of a system development as a specification of what should be
implemented or as a constraint of some kind on the system. Further the requirements are categorized as
Functional requirements focus on the “What” of the system and identify the “functions” and “data” related
requirements, and Non-functional requirements focus on the “How well” aspects of the system and identify
attributes like “performance”, ”maintainability”, “scalability” etc. Requirements engineering provides the
appropriate mechanism for understanding what the customer wants.
Requirements engineering can be divided into two main set of activities:(1) Requirements Definition (2)
Requirements Management. Requirements Definition consists of:(1) Requirements Elicitation or gathering of
Requirements. (2)Requirements Analysis (3) Requirements Documentation (4) Requirements Review.
Requirements Management consists of: (1) Requirements Change Management (2) Requirements
Traceability.
Traditionally, RE is performed in the beginning of the system development lifecycle. RE is an incremental and
iterative process, performed in parallel with other system development activities. RE activities cover the entire
system and software development lifecycle.
The spiral model of requirements engineering processes emphasis on continuous reassessment of the elicitation
and analysis and combines the iterative and sequential approaches. The spiral model of requirements
engineering is divided into four number of framework activities, also called task regions which are:
13
(1)Requirements Elicitation (2) Analysis and negotiation (3) Requirements documentation (4) Requirements
validation.
REMM is a three level model.
 Level 1 - Initial level,

 Level 2 - Repeatable level,
 Level 3 - Defined level.
The requirements engineering life cycle basically consists of three main activities, which are : Feasibility study,
Elicitation and Analysis, Validation.
CHAPTER # 02
REQUIREMENTS ELICITATION
2.1 Requirements Elicitation: An Overview

Requirements elicitation is essentially a communications process involving different communities currently
most of the elicitation takes place through meetings and interviews supported by telephonic conversations,
electronic mail and video conferencing. Though elicitation primarily takes place at the start of the project and
element of the elicitation takes place through the life cycle. New requirements may be proposed during design
and implementation and existing requirements may be modified or deleted.
In this phase of requirements engineering is basically focused on the gathering of requirements by asking the
customer the users and others to get the information that what the objectives for the system or product are, what
is to be accomplished, how the system or product fits into the needs of the business, and finally how the system
or product is to be used on a day to day basis. Requirements elicitation work as bridge between the user and the
developer.
Requirements elicitation requires collaboration of people with different backgrounds such as:
 Users with application domain knowledge
 Developer with solution domain knowledge (design knowledge, implementation knowledge).
14
On the one hand, the client and the users are experts in their domain and have a general idea of what the system
should do, but they often have little experience in software development. On the other hand, the developers
have experience in building systems, but often have little knowledge of the everyday environment of the users.
The purpose of elicitation is to get information about: the domain model from which the requirements are
written and the requirements from which system is Developed. There is famous quotation regarding the
requirements elicitation which was quoted by the software engineer is:
“You must get information out of clients’ minds

without damaging the clients or their minds! ”
Many times this information does not come out easily. The clients do not know it themselves. The clients do not
want to let it out (subconsciously). The requirements elicitation is the human activity involving interaction
between the user and the developer so. If you cannot do the human interaction right, you are not going to be
able to elicit, no matter what technology and methods you use. Technology and methods might help, but they
can also get in the way.
Requirements Elicitation might be described as eliciting a specification of what is required by allowing experts
in the problem domain to describe the goals to be reached during the problem resolution. This being so, we may
be limited to having a vague desire at the beginning of the process, such as "We want a new aircraft carrier",
and at the end of the process having a detailed description of the goals and some clear idea of the steps
necessary to reach the goals.
There are some important types of requirements elicitation which are :

1. Greenfield Engineering
 Development starts from scratch, no prior system exists, the requirements are extracted
from the end users and the client
 Triggered by user needs
2. Re-Engineering
 Re-design and/or re-implementation of an existing system using newer technology
 Triggered by technology enabler.
3. Interface Engineering
15
 Provide the services of an existing system in a new environment

 Triggered by technology enabler or new market needs
2.2 Requirements Elicitation Techniques

Before requirements can be analyzed, modeled or specified they must be gathered through an elicitation
process. There are many requirements elicitation techniques and approaches which have been proposed and
used in the past. There is no single approach that will always provide the best results in all cases. Requirements
elicitation is a collaborative decision making activity that involves users, analyst, developer, and customer. The
success of an elicitation approach depends not only on the maturity and diversity of these entities, but also the
complexity of the problem and the current understanding of the domain. The analyst must be aware of a set of
techniques and select the best subset of techniques to tackle different situations encountered in the project.
There are many techniques that have been evolved for requirements elicitation.
2.2.1 Traditional Techniques

The traditional technique is the most important and the first technique which was introduced to gather the
requirements. The traditional technique consists of two main techniques which are:
2.2.1.1 Questionnaires
To conduct the interviews the interviewer has to prepare the list of questions which should be asked at the time
of interview that’s why this technique is said to be the questionnaires or the context free questions. The main
strength of questionnaires is that large amounts of data can be gathered or collected from many users quickly. In
addition, data can be collected over a wide geographical area without incurring travel expenses. The
questionnaires are relatively inexpensive technique used for eliciting the requirements. If the questionnaires are
skillfully crafted, responses can be analyzed rapidly by computer.
There are some sort of questions which should be asked, the loaded question (“should you continue to be
provided with the high level of service you have received in the past?”), the leading question (“we should not
be providing this type of service to you, should we?”), the self-answering question (“how much time does it
take you to do this job? The current standard calls for one hour”), and the ambiguous question (“is the
documentation nice?”).
The analyst start the communication with the customer by asking the “Context free question” that is a set of
questions that will lead to a basic understanding of the problem, the people who want a solution, the nature of
16
the solution that is desired and the effectiveness of the first encounter itself. The first context free questions
focuses on the customer, the overall goals and the benefits. For example the analyst might ask :
 Who is behind the request for this work?
 Who will use the solution?
 What will be the economic benefit of a successful solution?
 Is there another source for the solution that you need?
 The next set of questions enables the analyst to gain a better understanding of the
problem and the customer to voice his or her perception about a solution.
 How would you characterize “good” output that would be generated by a successful
solution?
 What problems will this solution address?
 Can u show me the environment in which the solution will be used?
 Will special performance issues or constraints affect the way the solution is approached?
The final set of questions focuses on the effectiveness of the meeting:

 Are you the right person to answer these questions? Are your answers official?
 Are my questions relevant to problem that you have?
 Am I asking to many questions?
 Can any one else provide additional information?
 Should I be asking you anything else ?
These questions will help to “break the ice” and initiate the communication that is essential to successful
analysis.
2.2.1.2 Interviewing
The interview is the basic technique used to elicit the requirements. Interviews are designed to capture the same
type of data from users as questionnaires, but they are conducted in more depth because conducting interviews
is relatively expensive, a smaller number of managers and users are going to be conducting the interviews.
However the data gathered by using the interviewing technique often provide systems developers with a fuller
picture of the problem and opportunities. Interviews also give analyst the opportunity to note user reactions and
to probe for further information. For example, if a user’s response to a question puzzles the interviewer, he or
17
she can follow with a question that clarifies or digs deeper into the subject. This gives the interview a dynamic
quality not found in more impersonal questionnaires. We take the interviews to make the repository of the
requirements for further work and the interviews are also essential to search the undiscovered requirements by
exploring the solutions.
Because interviews are time consuming and take users away from their work, the person who is eliciting the
requirements should coordinate interview schedules with the managers of the workers that he or she wants to
interview. Some interviews establish rapport with users and obtain the information regarding the system easily,
where as others intermediate users, causing them to provide the little bit information regarding system. We
conduct the interviews because it is the direct communication or the bridge between the user and the developer.
18
2.2.2 Group Elicitation

This technique is also very power full to gather the requirements, in this technique the requirements are
gathered by the team the group that’s why this technique is said to be the group elicitation. The group elicitation
is done by using the following ways:
2.2.2.1 JAD (Joint Application Development)

JAD is a management process that is used to involve both users and technical staff on a project, using intense
concentrated and focused meetings for ensuring their collaboration. JAD is considered an extremely effective
way of handling projects and ensuring their success and is an industry “Best practice”.
JAD is based on the recognition that user involvement is critical to project success and is required through out
the life cycle. Users are in the best position to say what is required it also recognizes that technical is in the best
position to use technology effectively for solving s problem. JAD therefore uses all these resources together as
equal partners throughout the lifecycle for the success of the projects.
In JAD users and professionals work together to analyze and design the system the main goal of this approach is
to maximize the user involvement in the development process. JAD sessions can be used throughout the
systems development process but are particularly helpful during systems planning, requirements analysis and
systems design.
There are some important roles in JAD which are discussed below:
1. Sponsor
2. Facilitator
3. Scribe
4. Systems Specialist
Sponsor is the most important role in JAD. Sponsor is the top management person whose sponsor ship shows
management commitment.
Facilitator is the key person who is most directly responsible for the functioning of the JAD team, the
facilitator is also called the project leader. He or she is responsible for planning, executing and managing the
project. To be effective the facilitator should have leadership qualities, the respect of the team and a good
reputation.
19
The JAD meetings need to be conducted effectively; a very important role for this is that of the scribe also
called the record keeper who shall document the JAD sessions. The scribe gas to capture all the important
decisions and clearly record all identified action points, persons responsible, dates etc
Developers are the important stakeholders and are represented at the JAD sessions by their specialist. System
specialist also called information specialist have to design system according to users requirements and need to
see how technology can be best used for this purpose.
2.2.2.2 RAD (Rapid Application Development)

RAD is another approach that incorporates numerous state-of- the- art approaches in order to speed up the
systems development process and to deliver new system faster.
RAD is a software development process that allows usable systems to be built in as little as 60-90 days, often
with some compromises. RAD is used mostly for the following purposes:
1. To converge early toward a design acceptable to the customer

and feasible for the developers
2. To limit a project's exposure to the forces of change
3. To save development time, possibly at the expense of economy or
product quality.
RAD combats scope and requirements creep by limiting the project's exposure to change shortening the
development cycle and limiting the cost of change by incorporating it up-front before large investments are
made in development and testing."
Historically, RAD systems have tended to emphasize reducing development time, sometimes at the expense of
generating efficient executable code. Nowadays, though, many RAD systems produce extremely fast code.
Conversely, many traditional programming environments now come with a number of visual tools to aid
development. Therefore, the line between RAD systems and other development environments has become
blurred.
20
2.2.2.3 Requirements Workshop
The requirements workshop is designed to encourage consensus on the requirements of. the application and to
gain rapid agreement on a course of action, all in a very short time frame. With this technique, key stakeholders
of the project are gathered together for a short, intensive period.
A properly run requirements workshop has many benefits.

 It assists in building an effective team, committed to one common
 purpose: the success of this project.
 All stakeholders get their say; no one is left out.
 It forges an agreement between the stakeholders and the development team as to what the
application must do.
 It can expose and resolve political issues that are interfering with project success. .The output,
a preliminary system definition at the features level, is available immediately.
Preparing for the workshop

 Selling the workshop concept to stakeholders
 Ensuring the Participation of the Right Stakeholders
 Logistics
• Try and prevent Murphy ’s Law.
• Includes travel, lighting, end even afternoon sugar filled snacks.
 Warm-up materials
• Project-specific information.
• Out-of-box thinking preparation.
Brainstorming is the most important part of the workshop.
2.2.2.4 Brainstorming
21
Brainstorming involves both idea generation and idea reduction. The most creative, innovative ideas often
result from combining, seemingly unrelated ideas. Brainstorming can be an effective way to generate lots of
ideas and then determine which idea(s) best solves the problem. Brainstorming is a method of creative thinking
that is used to come up with ideas to solve problems. Have you ever had a tough problem that you couldn't
easily come up with a solution for easily? Well you probably did a little brainstorming before you came up with
a solution. Brainstorming can be done alone or in groups. The term "think-tank" refers to a group that
brainstorms. Studies show that group brainstorming is much more productive than doing it alone.
Most problems are not solved automatically by the first idea that comes to mind. To get to the best solution it is
important to consider many possible solutions. One of the best ways to do this is called brainstorming.
Brainstorming is the act of defining a problem or idea and coming up anything related to the topic - no matter
how remote a suggestion may sound. All of these ideas are recorded and evaluated only after the brainstorming
is completed.
Procedure to do Brainstorming
1. In a small or large group select a leader and a recorder (they may be the same person).
2. Define the problem or idea to be brainstormed. Make sure everyone is clear on the topic being
explored.
3. Set up the rules for the session. They should include
 Letting the leader have control.

 Allowing everyone to contribute.
 Stating that no answer is wrong.
 Recording each answer unless it is a repeat.
 Setting a time limit and stopping when that time is up.
4. Start the brainstorming. Have the leader select members of the group to share their answers.
The recorder should write down all responses, if possible so everyone can see them. Make sure not to evaluate
or criticize any answers until done brainstorming.
22
5. Once you have finished brainstorming, go through the results and begin evaluating the
responses. Some initial qualities to look for when examining the responses include
 Looking for any answers that are repeated or similar.

 Grouping like concepts together.
 Eliminating responses that definitely do not fit.
2.2.3 Storyboarding
The purpose of storyboarding is to gain an early reaction from the users on the concepts proposed for the
application. With storyboarding, the user's reaction can be observed very early in the lifecycle, well before
concepts are committed to code and, in many cases, even before detailed specifications are developed.
Effective storyboarding applies tools that are both inexpensive and easy to work with. Storyboarding is
extremely inexpensive, is user friendly, informal, and interactive, provides an early review of the user interfaces
of the system, is easy to create and easy to modify. Storyboards can be used to speed the conceptual
development of many different
facets of an application. Storyboards can be used to understand data visualization, to define and understand
business rules that will be implemented in a new business application, to define algorithms and other
mathematical constructs that are to be executed inside an embedded system, or to demonstrate reports and other
hardcopy outputs for early review. Indeed, storyboards can and should be used for virtually any type of
application in which gaining the user's reaction early will be a key success factor. In software, storyboards are
used most often to work through the details of the human-to-machine interface. In this area, generally one of
high vitality, each user is likely to have a different opinion of how the interface should work.
Storyboards can be categorized into three types, depending on the mode of interaction with the user:
 Passive Storyboards
 Active Storyboards
 Interactive Storyboards
Passive Storyboards Interaction with the user: passive, active, or interactive. Passive storyboard\' tell a story
to the user. They can consist of sketches, pictures, screen shots, PowerPoint presentations, or sample outputs. In
a passive storyboard, the analyst plays the role of the sys-tem and simply walks the user through the storyboard.
23
Active Storyboards Try to make the user to see “a movie that hasn’t been produced yet”. Active
storyboards are animated or automated, perhaps by an automatically sequencing slide presentation or an
animation tool or even a movie. Active storyboards provide an automated description of the way the system
behaves in a typical usage or operational scenario.
Interactive Storyboards Let the user experience the system in as realistic a manner as practical. They
require participation by the user in order to execute. Interactive storyboards can be simulations or mock-ups can
be advanced to the point of throwaway code. An advanced, interactive storyboard built out of throwaway code
can be very closed to throwaway prototype.
2.2.4 Prototyping
We usually apply different techniques to elicit the requirements in some cases it is possible to apply operational
analysis principle and drive a model of software from which a design can be developed. In other situations
requirements elicitation via the FODA (feature oriented domain analysis), QFD(Quality Function Deployment),
use cases or other brainstorming techniques is conducted, analysis principles are applied and a model of the
software to be built called a prototype is constructed for the customer and the developer assessment.
The prototype shows a partial result of the communication of requirements between the users and the analysts.
The prototype helps the users to extend their understanding of the needs and also improves the communication
between the users and the developers. Prototyping is frequently used to provide early feedback to customers and
users and to improve the communication of requirements between the analysts and the users. A prototype can
effectively provide the users are “look-and-feel” and convey a sense of how the system will work.
For maximum benefits the prototyping should be carried out in a systematic manner with the following steps
(also shown in figure 2.1):
 Establish goals for the prototype: Prototypes may be developed with different
objectives e-g to discuss the user interface, to establish the technical feasibility, to discuss functionality from a
given context, etc. if the developer or the end users do not know the objectives the prototype may create further
miss understanding.
24
 Define prototype features and functionality: In this step the detailed list of features and
functions that are to be demonstrated in the prototype are documented, discussed and agreed to this document
should not only state what will be in the prototype but also state what will not be included in the prototype.
 Get the prototype ready: In this step you will develop the prototype and review it
against the list of features and functionality, to ensure that all the required features and functionality are
developed.
 Evaluate the prototype: The prototype is an executed in this step. Users and
developers feedback is collected. This feedback typically includes new requirements, changes to user interface,
dropping of requirements, etc. the evaluation report is then used to elicit and analyze the new requirements.
25
There are two types of approaches to prototyping the evolutionary approach and the throwaway approach. In the
evolutionary approach which is often called the (open-ended approach), the prototype is built in such a way
that it can be used in the construction phase. The main benefit of the evolutionary approach is that a
considerable part of the system is developed during the requirements and the design stages. In the throwaway
approach (which is also called the closed-ended approach) to prototyping the use of the prototyping ends
once all the requirements are clearly documented. The prototype “System” is not used for the actual
construction of the system. Or we can say that using this approach, a prototype serves solely as a rough
demonstration of requirements.
Before a close-ended or open-ended approach can be chosen it is necessary to determine whether the system to
be built is amenable to prototyping. A number of prototyping candidacy factors can be defined: application area,
application complexity, customer characteristics, and project characteristics.
There are plenty of tools available for prototyping including fourth generation languages (4GT), reusable
software components, and prototyping environments.
Fourth generation languages (4GT): 4GT encompass a broad array of database query and reporting
languages, program and application generators and other very high level non-procedural languages. The 4GT
method of prototyping enables the software engineer to generate the executable code quickly they are ideal for
rapid prototyping.
Re-useable software components: Another approach to rapid prototyping is to assemble, rather than
build, the prototype by using a set of existing software components.
Formal specifications and prototyping environments: A number of formal specification languages and
tools have been developed as a replacement for natural language specification techniques. Developers of these
formal languages are in the process of developing interactive environments that: (1) enables an analyst to
interactively creates the language based specification of a system or software. (2) invoked automated tools that
translate the language based specifications into executable code. (3) and enable the customer to use the
prototype executable code to refine formal requirements.
26
Prototyping often reduces the uncertainties by providing a platform for experimentation and discussion. Though
prototyping is beneficial to many projects, the activity of prototyping needs to be carefully controlled.
2.2.5 Applying Use Case (Scenarios)

Use Cases, like storyboards, identify the who, what, and how of system behavior.
Use Cases describe the interactions between a user and a system, focusing on what they system “does” for the
user. The Use Case model describes the totality of the systems functional behavior.
A Use case is a complete course of events by an actor and it specifies the interaction that takes place between an
actor and the system [Jacobson]. It is a general event-response document between an actor (any stake holder)
and the system. Each interaction covers a specific aspect of processing. Actor can be end users or external
internal interface. Thus the Use cases are useful in various purposes like capturing requirements, prioritizing
and refining requirements, sizing, preparing an initial design and managing progress.
As requirements gathered as part of informal meetings the software engineer (analyst) can create a set of
scenarios that identify a thread of usage for the system to be constructed. The scenarios often called use cases
provide a description of how the system will be used. To create a use case the analyst must first identify the
different types of people that use the system or product these actors actually represent roles that people play as a
system operates. An actor is anything that communicates with the system or product and that is external to the
system it self. It is important to note that an actor and a user or not the same thing a typical user may play a
number of different roles when using a system where as an actor represents a class of external entities that play
just one role.
Because requirements elicitation is an evolutionary activity not all actors are identified during the first iteration.
It is possible to identify primary actors during the first iteration and the secondary actors as more is learned
about the system. Primary actors interact to achieve required system function and drive the intended benefit
from the system. They work directly and frequently with the software. Secondary actors support the system so
that primary actors do their work. Once actors have been identified use cases can be developed. The use case
describes the manner in which an actor interacts with the system.
The scenarios can be defined as: “A narrative description of what people do and experience as they try to make
use of computer systems and applications”.
2.2.6 QFD (Quality function deployment)
27
QFD is a quality management technique that translates the needs of the customer into technical requirements
for software. The word “Quality” in QFD denotes what a customer perceives as “Quality” and thus refers to the
customers requirements. QFD “concentrates on maximizing customer satisfaction from the software
engineering process”. QFD emphasizes and understanding of what is valuable to the customer and then deploys
these values throughout the engineering process.
QFD is customer driven it uses the customers requirements and prioritization to drive the functions that the
product shall have and determines how these functions are made available. Every function provided by the
product is based on some customer requirement and the relationship between the deployments and the
requirements is depicted as a quality matrix.
The methodology uses:
Quality from the customer’s perspective as the objective statement which gives the overall perspective, who
the customers are, what their requirements are and what QFD is trying to achieve.
Function is derived from quality and gives the product characteristics required to meet the customer
requirements.
Deployment derived from the function, means how the product shall provide the required features.
QFD identifies three types of requirements:

Normal Requirements: The objectives and goals that are stated for a product or system during meetings
with the customer. If these requirements are present the customer is satisfied.
Expected Requirements: These requirements are implicit to the product or system and may be so
fundamental that the customer does not explicitly state them. There absence will be a cause for significant
dissatisfaction.
Exciting Requirements: These features go beyond the customers expectations and prove to be very
satisfying when present.
2.2.7 CORE (Controlled Requirements Expressions )

CORE is an acronym for COntrolled Requirements Expression, a requirements elicitation, analysis and
specification method developed in the late 1970s and
refined during the early 1980s. CORE is a viewpoint-based method. Its premise is that any system can be
viewed from a number of "viewpoints" and that a complete picture of system requirements can only emerge by
putting together these various viewpoints.
28
Viewpoints considered in CORE include both functional viewpoints and non-functional

viewpoints. They are identified by partitioning the problem and also by using techniques like brainstorming.
This viewpoint identification and selection is the first step in a viewpoint-based analysis. Initial data gathering
is next done to get some broad level data on each viewpoint, to structure the viewpoints and to check
consistency from within and outside the viewpoints. Functional viewpoints are structured hierarchically.
In CORE, a viewpoint is seen as one that is responsible for producing or consuming data. Having identified all
such viewpoints, initial data gathering involves analyzing what data is produced or consumed by each such
viewpoint. Information is gathered for each functional viewpoint to understand how data flows for that
viewpoint. Detailed viewpoint analysis is done next for each viewpoint to understand the data, the viewpoint
actions and their trigger. Detailed analysis is done to understand the relationship between actions and data flows
of the viewpoint. It identifies what starts viewpoint actions and what stops them. Viewpoint actions could be
triggered by events or at a specific time or periodicity. They are stopped when the action is complete or a
specified number of iterations are over or a required output data is generated.
The CORE approach is fairly general purpose and yet flexible enough. It is suitable for concept exploration.
CORE insures that the requirements defined are more comprehensive and correct. The approach defines the
responsibilities for the various communities and the way they interact and arrive at the analysis. In CORE the
requirements specifications are put together by the users, customers and the analysts, not just the analyst alone.
2.2.8 IBIS (Issue Based Information System)

IBIS acronym for issue based information system. It is a methodology developed by Horst rittel and colleagues
during the early 1970s. One of the main concern in requirements is understanding the rationale behind them.
The rationale is necessary to make choices and prioritize between the requirements. It is also important for
another reason when the original analysts are no longer available informed decisions can not be taken without
knowing the rationale. A methodology that focuses on understanding the documentation of the rationale behind
the requirements is IBIS. IBIS is a simple and non-intrusive method that provides a framework for resolving
issues and gathering requirements while tracking the pending issues and also documenting the rationale behind
the requirements.
IBIS uses an issue-based approach. It focuses discussions on identifying and resolving issues, without allowing
the attention to move away from the underlying issue. The framework used in IBIS is:
 Question (Issue).
 Idea (Position).
29
 Argument (Justification).
By separating the three-questions, ideas and arguments, IBIS avoids getting caught in justifications and losing
track of the underlying question to be answered. To document the dialog, the three elements are documented
separately, with appropriate links
 A question is stated.
 The response is the idea (ideas) expressed and depicted indented one level
Under it.
 Arguments for (pro) or against (con) each idea are further represented in-dented
Under the idea.
By this clear documentation, discussions can stay more focused as repetitions of ideas and arguments can be
avoided. IBIS also ensures thus that the notes taken down during discussions are of consistent quality and easy
to use. The IBIS method is simple to use and learn and does not "intrude" on the way people work. By capturing
information in a consistent way and ensuring that important information is captured, it makes the requirements
elicitation more structured. IBIS allows easy identification of issues not yet discussed and tracking and closing
discussion on these. IBIS is an interesting concept and a useful way of staying focused in meetings and
documenting them consistently. It has limited scope and can be productive if used along with other elicitation
methodologies.
2.2.9 FODA (Feature Oriented Domain Analysis)

A well-know domain analysis methodology is FODA-FODA is the acronym for Features Oriented Domain
Analysis. The Software Engineering Institute (SEI) introduced FODA in 1990. The term "domain analysis" is
used for the process of identifying, collecting,
organizing and representing the relevant information in a domain. It uses the study of existing systems and their
development histories, knowledge captured from domain experts, underlying theory and emergent technology
within a domain.
The FODA methodology consists of three steps.

1) Context analysis This defines the extents (bounds) of the domain for analysis.
2) Domain Modeling This describes the problem space in the domain to be addressed by the software.
3) Architecture Modeling This gives the software architecture for implementing solutions.
30
Context analysis defines the scope of the domain, its relationships to other domains, inputs, outputs of the
domain and the high-level stored data requirements. It is expressed as a context model and may be done using
structure diagrams and context diagrams.
Domain modeling is concerned with identifying the commonalties and differences of various applications of
the domain. Domain modeling uses three different types of techniques and results in the following outputs:
 Information model-gives the information in the system and the relationships between the
entities, and can be expressed using means like Entity Relation-ship Diagrams.
 Features model-describes the features of the system as meaningful to the end users and is
useful for communicating to the users and obtaining a complete and consistent view of the domain.
 Functional model (also called operational model or behavioral model) structures the functions
and their sequencing and forms the base for developers to see how to provide the features needed by the users.
Architecture modeling is the next step in which the software architecture is defined. It includes identifying
concurrent processes and common modules.
The FODA methodology focuses on understanding the domain and the user's perspective. This focus is the main
strength of the methodology. The approach is relevant since all requirements, are (directly or indirectly) the
requirements of the users and are relevant to the application domain.
2.3 Requirements Elicitation Activities

Requirements elicitation activity can be broken down further into the following
tasks:
1) Fact-finding: consists of a study of the organization in which the target system
will operate and defining the proposed system's scope.
2) Requirements gathering: captures information from the viewpoint of
various users to identify what is to be built.
3) Evaluation: identifies inconsistencies in the gathered requirements and
examines why a requirement has been stated.
4) Prioritization: determines the relative importance of the requirements.
31
5) Consolidation brings together the information collected from the previous steps into a set of requirements
consistent with the goals identified during fact-finding.
2.3.1 Fact- Finding

The fact-finding task (also called the project definition) usually comprises:
 Identification of relevant users across multiple levels in the user organization.
 Identification of analysts with relevant domain and technical expertise.
 Determination of scope or reconfirmation of the scope.
 Identification of similar systems, if any.
 Identification of domain and architectural models.
 Conduct of technological survey, for later feasibility studies and risk assessment.
 Assessment of cost/implementation constraints imposed by the sponsor.
The output from fact-finding includes:

 A statement of the problem context and the scope of the proposed system.
 The overall objectives of the target system.
 Boundaries and interfaces for the target system.
In some simple or well-understood situations, much of this information may already be readily available in
some form. In many other situations the definition of the problem context may be the most difficult elicitation
activity and may need multiple iterations. The problem scope definition activities involved in these tasks are
vague and open to interpretation. It is best to have all the affected parties participate in this stage, including
users, developers and sponsors to promote shared ownership. If everyone involved agrees up-front to the scope
of the system, the instability of requirements can be minimized.
2.3.2 Requirement Gathering

With the scope of the system understood, the next task is to gather the requirements in more detail. The
requirements gathering exercise consists of:
 Creating a wish list for each user category across all levels of the user community.
32
 Classifying wish lists according to functional, non-functional, environment, and design

constraints.
In early stages of requirements elicitation, it is important to gather as much information as possible from users,
developers, and customers through the use of interviews, meetings, group discussions, observations,
simulations and questionnaires. These needs and requirements are verified against the overall objectives of the
target system expressed during fact-finding.
2.3.3 Evaluation
The requirements that have been gathered need to be evaluated to resolve inconsistencies
and also to understand why each requirement has been stated. This is done in the evaluation task. In this task the
analyst needs to do the following:
 For every requirement X, get answers to question "Why do you need X?"
 Convert any requirements stated as "how to" into the corresponding "what" is required.
 Capture rationale to support future requirements.
 Perform risk assessment, feasibility and cost/benefit analysis considering the technical, cost
and schedule concerns.
In this task, the analyst captures the rationale by eliciting and documenting issues, positions and arguments
through meetings, group discussions and inter-views.
Issues are identified where alternative selections can be made. Decisions describe the alternatives and the
rationale for the decision. This documentation of the rationale is extremely useful in later stages of requirements
elicitation.
2.3.4 Prioritization
In this task, the criticality of each requirement with respect to the mission is determined. The requirements are
then prioritized based on cost and dependency. This includes the study of how the system can be incremented,
and identification of appropriate architectural models that support incremental development.
Requirement prioritization is crucial to incremental/spiral and evolutionary development models. If
requirements are prioritized, then high priority requirements can be addressed first. Subsequent changes to
requirements are defined and re-examined, before low priority needs (which could change as well) are
implemented. This can result in cost and time savings when processing the inevitable changes to requirements
33
during system development. The requirements are typically prioritized based on cost, dependency, and user
needs. Knowing the rationale behind each requirement helps in deciding the priority.
2.3.5 Consolidation
Consolidation is required to put together all the requirements in a way that can
be analyzed further. The consolidation task comprises:
 Filling in as many "to be determined" (TBD) issues as possible.
 Validating that requirements are in agreement with originally stated goals.
 Removing inconsistencies.
 Resolving conflicts.
 Authorizing/verifying to move to the next step of development, i.e., detailed requirements
analysis.
An important aspect in consolidation is ensuring that the requirements obtained after this stage represent all the
stakeholders. Often, group development techniques, such as Joint Application Development (abbreviated as
JAD) are used for consolidating requirements. The consolidation can be done by single and as well as by the
elicitation community. The advantage of group development techniques is that they promote shared ownership
of the developed requirements, with an improved definition of scope as well as reduced chance for future
changes to requirements. If consolidation is done by a single elicitation community (such as the analysts)
following fact-finding, requirements gathering, and the other earlier stages, then the consolidation will be
viewed as the analysts' interpretation of the requirements, and may be criticized as not incorporating other
important interpretations as well.
The consolidation tasks might be performed primarily by the systems analyst, and the results of the elicitation
process communicated to the other involved communities through various strategies such as prototyping. This
validation of the requirements by all affected parties ensures that their concerns are met.
2.4 Summary
Requirements elicitation is essentially a communications process involving different communities currently
most of the elicitation takes place through meetings and interviews. In this phase of requirements engineering is
basically focused on the gathering of requirements by asking the customer the users and others to get the
information that what the objectives for the system or product are, what is to be accomplished. The purpose of
34
elicitation is to get information about: the domain model from which the requirements are written and the
requirements from which system is Developed.
The requirements Elicitation Techniques are categorizes as follows:
 Traditional Techniques
 Questionnaires and Surveys
 Interviews
 Analysis of existing documentation
 Group Elicitation
 Group brainstorming sessions
 RAD (Rapid Application Development)
 JAD (Joint Application Design)
 Prototyping
 Where there is great deal of uncertainty
 Early feedback from stakeholders is needed.
 Applying Use cases.
 QFD (Quality function Deployment).
 CORE (controlled requirements Expressions).
 IBIS (Issue Based information System).
 FODA (Feature Oriented Domain Analysis).
Requirements elicitation activity can be broken down further into the following tasks:
(1) Fact-finding (2) Requirements gathering (3) Evaluation (4) Prioritization (5)Consolidation.
CHAPTER # 03
REQUIREMENTS ANALYSIS
3.1 Requirements Analysis : An Overview

The purpose of the requirements analysis is to establish an understanding of the application domain and to
capture, formalize, analyze and validate the user requirements on the system to be built. Once requirements have
been gathered (or elicited) the requirements analysis phase is started. The main purpose of this phase is to
35
investigate the gathered requirements in detail, and also uses to categorize requirements and organizes them into
related subsets, explores each requirement in relationship to others, examines requirements for consistency,
omissions, and ambiguity and ranks requirements based on the needs of the customer / users. The requirements
analysis acts as a bridge between the system engineering and the software design. To build something we must
first understand what that “Something” is to be. The process of understanding and documenting this something
is called requirements analysis. Requirements generally express what an application is meant to do: generally
they do not try to express how to accomplish these functions. The key objective of the requirements analysis is
to describe the requirements in terms of relationships, provide a basis for the design and to provide a basis for
validation for the software after it is built. The requirements analysis phase starts in parallel with requirements
elicitation and involves refining and modeling the requirements to identify inconsistencies errors omissions and
other defects. Requirements analysis is usually done with the use of one or more system models that present an
abstract description of the system. These models also act as a bridge between the users, customer and the
developers as the models are easily understandable by all the parties. The output of requirements analysis is a
document generally referred to as a requirement specification of software requirement specification (SRS).
Requirements analysis provides pointers and inputs to further elicitation. Activities that are performed in
requirements analysis often overlap the requirements elicitation activities. Typical activities that may be
classified as requirements analysis are:
 Depiction of the scope of the system in the form of a diagram. This involves pictorial
representation of boundaries and interfaces between the system that is proposed and entities outside the
proposed system this is often called the system context diagram.
 Developing prototypes which users evaluate and provide further requirements or refine the
requirements. Prototypes help the users to visualize the proposed system better and increase the understanding
between the end users and the analysts.
 Performing feasibility analysis this typically includes estimation of the cost and confirming
that the requirements are technically feasible in the given hardware and the software environment.
 Modeling of the requirements which usually consist of various graphical representations of the
functions, data entities, external entities and the relation ships between them. It often includes the depiction of
the various “states” of the different entities and the “transformations” required to transition the entities from one
state to another.
36
3.2 Levels Or Categories Of Requirements Analysis

Debates have regard for some time on who “owns” requirements: the customer or the developers. To deal with
this issue we divide requirements analysis into two levels.
 Customer or C-requirements.
 Developer (Detailed) or D-requirements.
The first level documents the customer’s wants and needs, and is expressed in language clear to him. The
results are some times called customer requirements or C- requirements. The primary audience is the customer
community and the second way audience is the developer community. The second level documents the
requirements in a specific structured form. These are called developer requirements or D-requirements. The
primary audience for D-requirements is the developer community and the secondary audience is the customer
community.
3.2.1 Customer Or C – Requirements

When the development community begins requirements analysis, the customer is typically still forming
concepts of what he wants and needs. This is analogous to the requirements gathering phase between an
architect and a client. The analysis of requirements is a person to person activity, care fully organized to
produce the best application. The software engineer(analyst) gather the customer or C-requirements by different
techniques but usually the interviews are the best way to gather the C-requirements.
Road Map Of C- Requirements

The following figure shows the different steps of gathering the C-requirements. The first step is to identify the
“Customer or User”, then conduct the interview with the customer which is the main technique use to gather the
C-requirements which identifies that what the customer actually wants. After identifying the needs of the
customer the analyst is now able to write the C-requirements in a standard document. On that basis the analyst
will be further able to build the D-requirements which is the main purpose to write the C-requirements.
There are various ways to express the C-requirements:

 If the requirement is simple and stands alone, express it in clear sentences within an
appropriate section of the SRS.
37
 If the requirement is an interaction between the user and the application, express it via a use
case.
 If the requirement involves process elements, each taking inputs and producing outputs, then
use the data flow
 If the requirement involves states that are going to change at some particular event then express
these types of requirements via STD
Use cases are widely applicable for describing customer requirements because they capture user application
interactions. If a state – transition diagram expresses what the customer wants and needs, and the customer
understands the diagram, then its use is appropriate. The same holds for data flow diagrams. Data flow and
state-transition techniques are commonly used for expressing designs. If an application is required to track the
flow of orders within a company, then a data flow diagram (DFD) showing this process at a high level would be
an appropriate form for C-requirements, because the DFD is needed to express what is to be done.
3.2.2 Detailed or D – Requirements
38
Software engineers need a basis for design and implementation this basis consists of the detailed requirements
these are also called “specific requirements”, “functional requirements”, “developer requirements”, or “D-
requirements”. D-requirements consists of a complete list of specific properties and functionality that the
application must posses, expressed in final detail. Each of these requirements is numbered, labeled, and tracked
through implementation. They are consistent with and elaborate upon the C-requirements. The D-requirements
are intended to be ready primarily by developers. Customers are interested in them as well and are typically able
to understand and comment on many of them.
Road Map Of D – Requirements

The following figure shows a typical sequence of activities for gathering and documenting D-requirements.
There are five steps to obtain the D-requirements. The first step describes the ways in which specific
requirements can be organized. Then create the sequence diagrams, after that the third step is started in which
the D-requirements are written from the C-requirements. Then we begin writing tests for each of the specific
requirements simultaneously with writing the requirements themselves. Although D-requirements are written
primarily for developers the requirements and their tests are also reviewed with the customer. Then finally the
D-requirements should then be inspected and released. Once the D-requirements have been collected, the
project documents are updated or reflect the improved project knowledge.
39
The D-Requirements (“developer” or “Detailed” requirements) are written primarily for designers and
developers. They are created from C-requirements, as well as from continued customer interaction. The D-
requirements must be testable, traceable, and consistent.
3.2.2.1 Types Of D – Requirements

There are several types of requirements. This classification applies to both C- and D- requirements. During the
writing of C-requirements, these distinctions are often secondary to getting points across to the customer about
the application in general. The classification becomes much more significant when writing the D-requirements,
however, because it guides the development and testing process in different ways.
3.2.2.1.1 Functional Requirements

Functional requirements specify services that the application must provide. Functional requirements are
associated with specific functions, tasks or behaviours the system must support these requirements. In terms of
the ISO quality characteristics for evaluation, the functional requirements address the quality characteristic of
functionality.
As you might expect, functional requirements express how the system behaves. These requirements are usually
action oriented ("When the user does x, the system will do y.") Most products and applications, conceived to do
useful work, are rich with software functional requirements. Software is used to implement the majority of the
functionality. When you are defining functional requirements, you should seek a good balance between being
too specific in stating a requirement and being too general or too ambiguous. We have found that most
functional requirements can be stated in simple declarative statements. Experience has shown us that a one- or
two-sentence statement of a requirement is usually the best way to match a user need with a level of specificity
that a developer can deal with.
Functional requirements focus on purpose. They collectively define what a system does, typically in terms of
visible changes that you can effect in the system or that it can cause in the outside world. Functional
requirements are typically binary in nature: you either meet a requirement or you don’t.
A functional requirement specifies a function that a system has to perform:
 A functional requirement defines what must be done, not how to implement it.
40
 A functional requirement defines the transformation to be performed on the inputs to generate

the outputs (precondition/post condition).
3.2.2.1.2 Non Functional Requirements
Non-functional requirements may be more critical than functional requirements. If these are not met, the system
is useless. Define system properties and constraints e.g. reliability, response time and storage requirements.
Constraints are I/O device capability, system representations, etc. These non functional requirements specify the
timing constraints that the application must observe. Customers and developers negotiate constraints on elapsed
time for computations, RAM usage, secondary storage usage etc.
Non-Functional Requirements in Software Engineering presents a systematic and pragmatic approach to

`building quality into' software systems. Systems must exhibit software quality attributes, such as accuracy,
performance, security and modifiability. However, such non-functional requirements (NFRs) are difficult to
address in many projects, even though there are many techniques to meet functional requirements in order to
provide desired functionality. This is particularly true since the NFRs for each system typically interact with
each other. Before we go into specifics we will state some overall goals and requirements to our infrastructure,
these goals are actually the non functional requirements.
TYPES OF NON FUNCTIONAL REQUIREMENTS

Performance Requirements: performance requirements are a critical part of real time applications in which
actions must complete with in specified time limits.
Performance requirements represent the performance the system is required to exhibit to meet the needs of
users.
 What is the acceptable throughput rate?
 What is the acceptable response time?
Reliability and Availability Requirements: Reliability requirements specify reliability in quantified terms.
This kind of requirement recognizes that applications are unlikely to be perfect and so circumscribes their extent
of imperfection. Availability closely related to reliability quantifies the degree to which the application is to be
available to its users.
41
Usability: The system will not be used directly by users of NFR but will be more of an
API to the rest of NFR. Thus, we focus on making the interface clean and simple, rather than providing services
to users.
Control or Security Requirements: Control requirements represent the environment in which

the system,
 Must access to the system or information be controlled?
 What are the privacy requirements?
 Does the criticality of the data necessitate the need for special handling (backups, offsite
storage, etc.) of the data?
Security is an important issue in an open, distributed system. It is also a large field far beyond the scope of our
project. These requirements may affect the selection of hardware and operating system, and the design of
interfaces and database components.
Error Handling: This category of requirements explains how the application must respond to errors in its
environment. For example what should the application do if it receives a message from another application
which is not in an agreed upon format ? these are not errors generated by the application itself. In some cases
error handling refers to actions which the application should take if it finds it self having committed an error
because of a defect in its construction.
Efficiency Requirements: Efficiency requirements represent the systems ability to produce outputs with
minimal waste.
 Are there duplicate steps in the process that must be eliminated?
 Are there ways to reduce waste in the way the system uses it resources?
Information Requirements: Information requirements represent the information that is pertinent to

the users in terms of content, timeliness, accuracy, and format.
 What are the necessary inputs and outputs? When must they happen?
 What is the required data to be stored?
 How current must the information be?
 What are the interfaces to external systems?
42
Interface Requirements: These requirements describe the format with which the application
communicates with its environment. These requirements define internal or external control and data flows.
An interface is a boundary between two systems. It can be described in terms of what is exchanged across the
boundary.
• Communication Interfaces.
The networks and protocols to be used.
• Hardware Interfaces.
The computer hardware the software is to execute on.
• Software-Interfaces.
How the software should be compatible with other software: applications, compilers, operating systems,
programming languages, database management systems.
• User Interfaces.
Style, format, messages, responsiveness.
Service Requirements:Service requirements represent needs in order for the system to be reliable, flexible, and
expandable.
 Who will use the system and where are they located?
 Will there be different types of users?
 What are the appropriate human factors?
 What training devices and training materials are to be included in the system?
 What are the reliability/availability requirements?
 How should the system be packaged and distributed?
 What documentation is required?
Economy Requirements: ·
Economy requirements represent the need for the system to reduce costs or increase profits
 What are the areas of the system where costs must be reduced?
 How much should costs be reduced or profits be increased?
 What is the timetable for development?
 What are the budgetary limits?
43
Constraints: Design or implementation constraints describe limits or conditions on how the

application is to be designed or implemented. These requirements are not intended to replace the design process.
They merely specify conditions imposed upon the project by the customer, the environment, or other
circumstances. Constraint requirements set restrictions on how the user requirements are to be implemented.
Maintainability Requirements: - These requirements can only be verified in the operations phase.
Maintainability is enhanced by:
 Use of a high-level programming language.

 Minimizing the volume of code.
 Use of tools that allow easy modifications.
 Building in features to allow to locate faults quickly.
 Provision of remote maintenance facilities.
 Assigning parameter values at runtime.
3.3 Design Constraints

The third class of requirements design constraints typically imposes limitations on the design of the system or
the processes we use to build a system. For example,
Usually, a requirement allows for more than one design option; a design is a conscious choice among options.
Whenever possible, we want to leave that choice to the designers rather than specifying it in the requirements,
for they will be in the best position to evaluate the technical and economic merits of each option. Whenever we
do not allow a choice to be made, the design has been constrained, and a degree of flexibility and development
freedom has been lost.
We'll define design constraints as
“ Restrictions on the design of a system, or the process by which a system is developed, that do not affect the
external behavior of the system but that must be fulfilled to meet technical, business, or contractual
obligations.”
44
Design constraints can also be found in the developmental infrastructure immediately surrounding the system to
be developed. These usually include
 Operating environments: "Write the software in desired language."
 Compatibility with existing systems: "The application must run on both our new and
old platforms."
 Application standards: "The developer must follow some particular standard such as
ISO etc."
 Corporate "best practices" and standards: "Compatibility with the legacy data base
must be maintained."
Another important source of design constraints is the standards under which the project is being developed.
Almost all projects will have some design constraints. Generally, the best way to handle them is to follow these
guidelines.
 Distinguish them from the other requirements.
 Include all design constraints in a special section of your collected requirements package,
or use a special attribute so that they can be readily aggregated. That way, you can easily find them
and review them when the factors that influenced them change.
 Identify the source of each design constraint. By doing so, you can use the reference later
to question or to revise the requirement.
 Document the rationale for each design constraint. In effect, write a sentence or two
explaining why the design constraint was placed in the project. Such as, "Why did we put this
constraint in there?".
3.4 Requirements Analysis Principles

However all analysis methods are related by a set of operational principles:
 The information domain of a problem must be represented and understood.
 The functions that the software is to perform must be defined.
 The behavior of the software (as a consequence of external events) must be represented.
 The models that depict information, function, and behavior must be partitioned in a
manner that uncovers detail in a layered (or hierarchical) fashion.
45
 The analysis process should move from essential information towards implementation
detail.
By applying these principles, the analyst approaches a problem systematically. The information domain is
examined so that function may be understood more completely. Models are used so that the characteristics of
function and behavior can be communicated In a compact fashion. Partitioning is applied to reduce complexity.
Essential and implementation views of the software are necessary to accommodate the logical constraints
imposed by processing requirements and the physical constraints imposed by other system elements. In addition
to these operational analysis principles, Davis [DAV95a] suggests a set of guiding principles for requirements
engineering:
 Understand the problem before you begin to create the analysis model. There is a
tendency to rush to a solution, even before the problem is understood. This often leads to elegant
software that solves the wrong problem!
 Develop proto~ that enable a user to understand how human/machine interaction will
occur. Since the perception of the quality of software is often based on the perception of the
"friendliness" of the interface, prototyping (and the iteration that results) are highly recommended.
 Record the origin of and the reason for every requirement. This is the first step in
establishing traceability back to the customer.
 Use multiple views of requirements. Building data, functional, and behavioral models
provide the software engineer with three different views. This reduces the likelihood that something
will be missed and increases the likelihood that inconsistency will be recognized.
 Rank requirements. Tight deadlines may preclude the implementation of every software
requirement.
 Work to eliminate ambiguity. Because most requirements are described in a natural
language, the opportunity for ambiguity abounds. The use of formal technical reviews is one way to
uncover and eliminate ambiguity.
The Information Domain
46
The first operational analysis principle requires an examination of the information domain and the creation of
the data model. The information domain contains three different views of data and control as each is processed
by the computer program.
1) Information content and relationships (data model),
2) Information flow, and
3) Information structure.
Information Content: - represents the individual data and control objects that constitute some larger collection
of information transformed by the software.
Information Flow: - represents the manner in which the data and control change as each moves through a
system.
Information Structure represents the internal organization of various data and control items. Are data and
control items to be organized as an n-dimensional table or as a hierarchical tree structure? Within the context of
the structure, what information is related to other information? Is all information contained within a single
structure or are distinct structures to be used? How does information in one information structure relate to
information in another structure? These questions and others are answered by an assessment of information
structure.
Modeling
The second and third analysis operational principle gives the concept of information modeling. We create
functional models to gain a better understanding of the actual entity to be built. When the entity is a physical
thin, we can build a model that is identical in form and shape but smaller in scale. The modeling principle is
used to represent the information that software transforms, the functions (and sub functions) that enable the
transformation to occur, and the behavior of the system as the transformation is taking place. The second and
third operational analysis principles require that we build models of function and behavior.
Functional models software transforms information, and in order to accomplish this, it must perform at
least three generic functions: input, processing and, output. When functional models of an application are
created, the software engineer focuses on problem specific functions. The functional model begins with a single
context level model (i.e the name of the software to be built). Over a series of iterations, more functional detail
is provided, until a thorough delineation of all system functionality is represented.
47
Behavioral model most software responds to events from the outside world. This stimulus/response
characteristic forms the basis of the behavioral model. A behavioral model creates a representation of the states
of the software and the events that cause software to change state.
Models created during requirements analysis serve a number of important roles:
• The model aids the analyst in understanding the information, function, and behavior of a
system, thereby making the requirements analysis task easier and more systematic.
• The model becomes the focal point for review and, therefore, the key to a determination of
completeness, consistency, and accuracy of the specifications.
• The model becomes the foundation for design, providing the designer with an essential
representation of software that can be 'mapped' into an implementation context.
Partitioning
Problems are often too large and complex to be understood as a whole. For this reason, we tend to partition
(divide) such problems into parts that can be easily understood and establish interfaces between the parts so that
overall function can be accomplished. The fourth operational analysis principle suggests that the information,
functional, and behavioral domains of software can be partitioned.
In essence, partitioning decomposes a problem into its constituent parts. Conceptually be establish a hierarchical
representation of function or information and then partition the upper most element by
1) Exposing increasing detail by moving vertically in the hierarchy or

2) Functionally decomposing the problem by moving horizontally in the hierarchy.
Essential And Implementation View

An essential view of software requirements presents the function to be accomplish and information to be
processed without regard to implementation details. The implementation view of software requirements
presents the real world manifestation of processing functions and information structures. In some cases a
physical representation is developed as the first step in software design. However, most computer based systems
are specified in a manner that dictates accommodation of certain implementation details the analyst must
recognize the constraints imposed by predefined system elements and consider the implementation view of
function and information when such a view is appropriate.
48
Software requirements engineering should focus on what the software is to accomplish, rather than on How
processing will be implemented. However the implementation view should not necessarily be interpreted as a
representation of “How”. Rather an implementation model represents the current mode of operation that is the
existing or proposed allocation for all system elements the essential model (of function or data) is generic in the
sense that realization of function is not explicitly indicated.
3.5 Methodologies And Tools Used For Requirements Analysis:

The greater challenge is that how to express clearly what customer want and need. Words alone can be
appropriate to express the customer needs, but for many applications these words are not sufficient so for that
the narrative text needs to be supplemented by various kinds of tools through which the engineers can clearly
express the customer’s concept. Some of the most widely used tools for requirements analysis includes the data-
flow diagrams, entity-relationship diagrams, object-class models, state-transition diagrams and use cases.
3.5.1 DFD ------- Data – Flow Diagrams

Data flow diagrams are used to study the manner in which information enters a system and the manner in which
it is transformed as it flow through the system. Data flow diagrams graphically represents the system using
symbols for data source/ destination (also called external entity), process, data flow and data store. Multiple
data flow diagrams are used to depict an existing or proposed system the first diagram is also called “Context
diagram” or “level-0 diagram” sets the context of the system with respect to the major inflows and outflows
from the system. The next level (level-1) of the diagram explores the system into the high level processes and
depicts the interactions between these processes. Each process from the level-1 DFD can now be broken down
into lower level DFDs.
In data flow diagrams the nodes shown as circles or rectangles represent processing units. The arrows among
them denote the flow of data. Data stores are places where data resides such as data bases are denoted by a pair
of horizontal lines enclosing the name of the data store. Suppose for example that our customer is trying to
explain a kind of banking application that she wants starting with deposits into an account. This deposit function
might be getting the deposit from the user, and checking the deposit transition to make sure that it is legitimate.
These functions are represented by circles in figure. Next the type of data flowing between these functions is
noted on the figure, the account number and the deposit amount. The user is involve too and so should be
represented.
49
The DFD serves two purposes: (1) to provide an indication of how data are transformed as they move through
the system and (2) to depict the functions (sub functions) that transform the data flow. The DFD provides the
additional information that is used during the analysis of the information domain and serves as a basis for the
modeling of the function.
A data flow diagram (DFD) is a graphical representation that depicts information flow and the transform that
are applied as data move from input to output. The basic form of data flow diagram is known as a data flow
graph or a bubble chart.
3.5.2 ERD ------ Entity Relationship Diagram

The ERD (Entity relationship diagram) depicts the data entities of the system and the relationships between
these data entities. During the requirements analysis stage we should use the ERD (Entity relationship diagram)
technique to represent high level logical groups of information and the connection between these logical groups
of information. In the design phase of development we can use the ERD (Entity relationship diagram) technique
for depicting the physical files and tables and the relationship between these tables. An entity in the context of
the ERD (Entity relationship diagram)is in the requirements analysis phase is a real world object within the
scope of the system that we plan to build, and about which we need to hold some information. For each entity
you will have to identify “attributes” which are similar to the columns in file or table definition. Entities are
50
related to each other via the relationships. An ERD is pictorial representation of the entities their attributes and
the relationships between the entities. An ERD (Entity relationship diagram) provides a mechanism to represent
the association between the various entities and provides the analyst with a concise notation to depict data in the
context of the proposed system. Further it acts as a primary input for data base design of the system. ERD
(Entity relationship diagram) looks only at the relationships of data in the system independent of the processing
and can not be used for functional modeling.
A set of primary components are identified for the ERD (Entity relationship diagram): data objects, attributes,
relationships and various type indicators. The data objects are represented by a labeled rectangle. Relationships
are indicated with a labeled line connecting objects. In some variations of the ERD (Entity relationship
diagram) the connecting line contains a diamond that is labeled with the relationship. Connections between data
objects and relationships are established using a variety of special symbols that indicate cardinality and
modality.
Cardinality is the specification of the number of occurrences of one object that can be related to the number of
occurrences of another object. Cardinality is usually expressed as simply one or many. Following are the
possible combinations of one and many, two objects can be related as:
• One-to-One (1 : 1) An occurrence of object “A” can relate to one and only one
occurrence of object “B” and an occurrence of “B” can relate to only one occurrence of “A”.
• One-to-Many (1 : N) One occurrence of object “A” can relate to one or many occurrences
of object “B” but an occurrence of “B” can relate to only one occurrence of “A”.
• Many-to-Many (M : N) An occurrence of object “A” can relate to one or many
occurrences of object “B” while an occurrence of “B” can relate to one or more occurrences of “A”.
Cardinality defines the maximum number of objects that can participate in a relationship.
Modality cardinality does not provide an indication of whether or not a particular data object must participate
in the relationship. To specify this information the data model adds modality to the object / relationship pair.
The modality of a relationship is 0 if there is no explicit need for the relationship to occur or the relationship is
optional. The modality is 1 if the occurrence of the relationship is mandatory.
3.5.3 OCD ------- Object Class Diagrams
51
Object models created during requirements analysis may be used to represent data as well as processing and
hence object model attempt to combine the features of the DFDs as well as ERDs. Object models used during
requirements analysis contain representation of objects from the real world. An object class is an abstraction of
a set of object that have common attributes and services or operations provided by that object. Object class
diagram shows how object classes are related to each other, how objects can be combined to form aggregate
objects and how objects use services provided by other objects. Object models are used where modeling the
behavior of objects makes sense. Object modeling is an obvious choice for object oriented analysis and design
as these models form the back bone of object oriented methods. They can be used to depict conceptual models,
specifications and implementation models.
We will concentrate on an object oriented style for organizing requirements in which categorization is first
identified the equivalent of selecting classes then the individual requirements are placed into the resulting
categorizes or classes. There are two approaches to this one regards the classes as applicable for organizing the
requirements but does not consider them necessarily usable for the actual design. Another approach followed in
the case study does use the classes developed for the requirements in the actual object oriented design and
implementation.
3.5.4 STD -------- State Transition Diagrams

STD (State transition diagram) is a behavioral model of the system that indicates how the proposed system will
behave in response to external events. States are some time called phases or stages. A state transition diagram
represents various “states” of the system and the manner in which transition will be made from one state to
another on receiving a stimulus. STD is typically used to model real time and process control type of systems.
The STD can be examined by the user and the analyst to confirm that the invalid transitions are not required and
all other transitions are valid. STD can be used for a whole system or a portion of a system. How ever they are
ideal for describing the behavior of a single object. STD help the users, analysts and designer understand the
intended behavior of the system, by providing a compact, language independent visual representation on certain
aspects of the system. STD help in ensuring that all the required states and permitted transitions are understood
and documented and that the system does not permit unnecessary transitions. In large complex systems it is near
to impossible to depict all possible states in a single diagram and verify the correctness and completeness. In
such cases the state transition diagram may be structured into high and low level. STD do not show processing
that is required it shows only the states and events to the extent that these events cause a change in the state of
52
the system. The STD does not provide any processing logic for the developers to build software and for this
reason just STD are not an adequate technique to model requirements. STD should typically be used to
complement other techniques.
STD indicates how the system behaves as a consequence of external events. To accomplish this the STD
represents the various modes of behavior called states of the system and the manner in which transitions are
made from state to state. State transition model is a good way to explain the concept of operations. State
transition models are commonly used as design tools as well.
3.5.5 Use - Cases

Since early days of requirements elicitation and analysis, analysts have been using “scenarios” to describe to the
user how the user will interact with the system. An object oriented method this is called the “use case”
approach. Though we discuss in the context of requirements analysis, it is also a very powerful tool during
requirements elicitation, documentation and review.
A use case is a description of the interactions between the “system” and an “actor” external to the system. The
actor could be a person, a group of persons, or another system that interacts with the proposed system. The use
case describes all the steps that the actor and the proposed system ill need to perform to achieve a desired
objective. Use case diagrams provide a high level visual representation of the user requirements. Once the use
cases and the actors are identified, the following questions may be asked by the analyst to gather details
regarding the use case:
 what is the actor trying to accomplish here?
 What information will the actor have to provide the system?
 What information will the system have to provide the actor?
 In what sequence will the information exchange take place?
Requirements are often naturally expressed as an interaction between the application and an agency external to
it, such as the user, the use case, is a very useful way to express customer requirements in the form of such
interactions. A use case is identified first by its name, and by the type of the user of the application called the
actor. It consists of a typical interaction between an actor and the application.
In UML notation, an ellipse denotes a use case and the agency which is external to it is denoted by an actor.
Use cases are useful for specifying requirements, design and test cases. Since high level use cases can express
53
the customer’s vision of how the application is to work that all will be include in the section of software
requirement specification (SRS).
As requirements are gathered by several informal meetings or applying the gathering techniques after that the
software engineer (analyst) can create a set of scenarios that identify a thread of usage for the system to be
constructed. The scenarios often called use cases provide a description of how the system will be used. To
create a use case the analyst must first identify the different types of people (or devices) that use the system or
product. These actors actually represent roles that people (or devices) play as the system operates. Define
somewhat more formally, an actor is anything that communicates with the system or product and that is external
to the system itself.
It is important to note that an actor and a user are not the same thing. A typical user may play a number of
different roles when using a system, whereas an actor represents a class of external entities (often, but not
always, people) that play just one role. Once actor has been identified, use cases can be developed. The use
cases describe the manner in which an actor interacts with the system. In general a use case is simply a written
narrative that describes the role of an actor as interaction with the system. Use case provides an unambiguous
scenario of interaction between an actor and the software, that scenario will be perceived differently by different
actors.
3.6 Summary
The purpose of the requirements analysis is to establish an understanding of the application domain and to
capture, formalize, analyze and validate the user requirements on the system to be built. Once requirements have
been gathered (or elicited) the requirements analysis phase is started. The output of requirements analysis is a
document generally referred to as a requirement specification of software requirement specification (SRS).
The requirements analysis are divided into two levels.

(1)Customer or C-requirements.
(2) Developer (Detailed) or D-requirements. The first level documents the customer’s wants and needs, and is
expressed in language clear to him. The results are some times called customer requirements or C-
requirements. The second level documents the requirements in a specific structured form. These are called
developer requirements or D-requirements. There are three main types of D-requirements (1) Functional
Requirements (2) Non-Functional requirements and (3) Design Constraints.
54
There are some analysis principles, by applying these principles, the analyst approaches a problem
systematically. The information domain is examined so that function may be understood more completely.
Models are used so that the characteristics of function and behavior can be communicated In a compact fashion.
Partitioning is applied to reduce complexity. Essential and implementation views of the software are necessary
to accommodate the logical constraints imposed by processing requirements and the physical constraints
imposed by other system elements.
The greater challenge is that how to express clearly what customer want and need. Words alone can be
appropriate to express the customer needs, but for many applications these words are not sufficient. So for that
the engineers used tools for requirements analysis includes the data-flow diagrams, entity-relationship diagrams,
object-class models, state-transition diagrams and use cases.
55
Chapter#04: Requirements Documentation
CHAPTER # 04
REQUIREMENTS DOCUMENTATION
4.1 Requirements Documentation : An Overview

Documentation is the descriptive information (e-g hardcopy manuals, online help files, web sites) that portrays
the use and/or operation of the system. Requirements documentation is essential as this is the only lasting
impression of the requirements elicitation and analysis process that is available to the development team, the
users and the customer as the system progresses to the later parts of the software lifecycle. The requirements
document usually called the software requirements specification (SRS) forms the basis for development as well
as testing activities. The SRS is typically used by the following entities:
 Customers and users for understanding what they are expected to get.
 Project Managers to estimate and plan the project to deliver the system.
 Designers and programmers to know what to build.
 Testers to prepare for testing activities.
 Maintenance team for understanding the system that they will maintain.
 Trainers to prepare the training material for training the end users.
 Users to understand the proposed system and prepare for the change over.
The software requirements specification (SRS) is produced at the end of the elicitation and analysis tasks. The
SRS may be documented in a combination of natural language textual narrative, interleaved with graphical
models, schematic and formal specification languages. The SRS needs to include all requirements and the
authors should not assumed that certain requirements are “obvious”.
The objective of documentation is to allow an independent person to review the system and to understand the
basis for its coding. Software documentation is intended to help scientists, engineers and programmers who
develop or review software to deal with the complexity of software products.
A written Software Requirements Document is the principal way to record software requirements. The project
manager and the software developer work together to record the agreements made as requirements are defined.
A software prototype, accompanied by supporting text, may also function as a requirements document. The
documentation of any system describes the purpose and implementation requirements of the system. Further the
65
Chapter # 04: Requirements Documentation
contents are the major part of the documentation means the document is fully depend on what it actually
contains means the person who is going to write the document of any system that person should keep the
scenario in mind that on what this document will emphasize more in which area of the system. In some cases
the document is emphasize on the requirements when the documentation is written before the design phase and
some times it focuses on the design strategies in that case if the document is written before the implementation
phase, and etc. Means the documentation is basically depends on the contents which are included by the
software engineer. When conducting research, you must credit the sources you used which contributed to your
final product. This attribution, or documentation, serves several purposes: 1) It provides a way for your
readers (or professor) to read more about your topic; 2) It allows readers to evaluate the sources you used to
reach a conclusion with which they may or may not agree; and 3) Documentation is necessary so that you will
not appear to be plagiarizing, or claiming as your own, someone else's work.
The Software Requirements Document contains the requirements for a software product:
 What the product must do

 Other attributes the product must have.
The Software Requirements Document (SRD) defines the following:
 Defines the planned features and functions of the software product.

 Describes other qualities that the software must have, such as usability attributes or
regulatory compliance.
 Clearly defines and prioritizes the customer requirements and software capabilities and
features that the engineering team must deliver in the final software product.
 Clearly defines the target market: business problem, user requirements, and market
opportunity.
 Identifies existing solutions and competitive products.
 Compares and contrasts the features, costs and capabilities of the product under
development with existing commercial products.
 Identifies long-term plans for future releases and features.
 Identifies maintenance and support costs.
57
4.2 Characteristics Of SRS Document

The requirements specification document typically called as the software requirements specification (SRS)
should address the issues related to functionality external interfaces, non-functional requirements as well as
design constraints. A “good” SRS document has the following characteristics:
 Completeness
 Clarity
 Correctness
 Consistency
 Modifiability
 Traceability
 Feasibility
 Testability
4.2.1 Completeness
This is the one of the most difficult to spot. If requirements elicitation doesn’t involve representatives of
different types of users the complete set of requirements may not be elicited. Missing requirements are difficult
to track since they are not visible. We can aim for high degree of completeness of requirements by ensuring the
following:
 Elicitation of the requirements from all the “Stakeholders”.
 Focusing on user tasks, problems, bottlenecks and improvements required; rather than the
system functionality.
 Ranking or prioritizing each requirement (functional as well as non-functional) for importance.
Prioritizing requirements guide customers to get more careful considerations to each requirements, and this
brings to surface any hidden assumptions that they may have made.
 Marking areas where requirements are not known as “To Be Determined” (TBD), along with a
description of why the requirement is still TBD and a description of what needs to be done to eliminate the TBD
(including who and when).
 Resolving all TBDs before the design phase.
58
To be considered “Complete” the SRS document should contain all functional and non-functional requirements
and features that are expected in the system. This includes the identification of all realizable classes of valid and
invalid input data and the specification of the expected system responses to these input data.
4.2.2 Clarity
The documented requirements should need to only a single interpretation, independent of the person or the time
when the interpretation is done. The SRS need to be unambiguous to the authors, the users, other reviewers as
well as the developers and testers who will use the document. Focusing on clarity only for developers and
testers may prove insufficient if such clarity reduces the understandability of the SRS for the users. Here are
some issues related to clarity:
Since natural language is imprecise and ambiguous in nature any SRS written in natural language needs to
reviewed by an independent entity (independent of the analyst, developers, and users) to identify ambiguous use
of the natural language.
 One way of avoiding ambiguity is to write the SRS in a requirement specification language,
which has a processor that detects many of the semantic, syntactic and lexical errors. How ever such languages
take time to learn and many users find them unintelligible.
 The requirements may also be expressed using requirements analysis and modeling techniques
(dataflow diagrams, use-cases, etc). These techniques improve the precision of the requirements however the
initial effort in converting the requirements into the models may be disproportionately high for small systems.
4.2.3 Correctness
The SRS can be considered as correct if every requirement stated in the SRS is required in proposed system.
There are no real tools or procedures that ensure correctness. If there are any preceding documents then the
“requirements” from those earlier documents need to be traced to the SRS. In addition all stakeholders specially
users need to review the SRS and confirm that the requirements stated in the SRS correctly reflect their needs.
4.2.4 Consistency
Requirements at all levels must be consistent with each other. Any conflict between requirements within the
SRS must be identified and resolved. The types of conflicts that are likely to be found in an SRS are:
59
 Characteristics (format, details) of a real world entity interacting with the system may be
conflicting.
 There may be a logical or temporal conflict between two specified items.
 The terminology used for some entities/events may be different.
4.2.5 Modifiability
The SRS needs to be documented in such a manner that a history of changes can be contained in the document.
It will also be necessary to be able to highlight and trace the changes to the requirements as we progress through
the project. Certain good practices that can lead to high modifiability are:
• Minimal Redundancy Though redundancy itself is not an error, it can lead to
inconsistencies when changes are incorporated.
• Labeling If requirements are labeled (or numbered), it is easy to pinpoint the
requirements that have changed. This includes labels and references to figures, tables, diagrams and appendices
in the SRS.
According to IEEE standard 830-1993 an SRS is said to be modifiable if “its structure and style are such that
any changes to the requirements can be maid easily, completely and consistently while retaining its structure
and style”.
4.2.6 Traceability
Labeling or numbering of requirements provides a mechanism to trace each requirement through the design,
into the test plans, test cases and source code. Fine grained, structured and precise statements are much more
preferable to large, narrative paragraphs. Expected traceability is of two types:
• Backward traceability to the documentation and other work products created prior to the
requirements phase. This will depend upon how well referencing and labeling has been provided in the earlier
documents/ work products.
• Forward traceability this will depend upon how each requirement in the SRS is
labeled/number. Forward traceability is extremely important as this is one of the ways of tracing a requirement
to its implementation.
60
4.2.7 Feasibility
Though it may not be possible to confirm the feasibility of implementation of all requirements, any requirement
which is apparently infeasible, should be eliminated from the SRS, after giving the reasoning.
4.2.8 Testability
The SRS needs to be stated in such a way that it is possible for the tester to create test plan and confirm
whether the requirements are met or not. Typical statements in a SRS which may be non testable or statements
which contain phrases like “user friendly”, “reasonable response” , “fairly accurate”. Statements that are non
testable and non verifiable need to be identified and removed or revised.
4.3 Contents Of SRS Document

The SRS template should be selected or defined at the start of the requirements elicitation activities, so that the
contents of the documents evolve and buildup as the requirements elicitation and analysis activities progress.
Following are the contents of the SRS:
Introduction
The introduction sets the tone of the document by providing a background to the customer, users, development
team and the context of the proposed system. This also describes the purpose of the SRS, the intended audience,
the structure of the SRS, the terminology and abbreviations used, any conventions used and lists other
documents referenced.
 Purpose of this document

Describes the purpose of the document, and the intended audience.
 Scope
Describes the scope of this requirements definition effort. Introduces the requirements elicitation team,
including users, customers, system engineers, and developers.
This section also details any constraints that were placed upon the requirements elicitation process, such as
schedules, costs, or the software engineering environment used to develop requirements.
61
 Overview
Provides a brief overview of the product defined as a result of the requirements elicitation process.
 Business-Context
Provides an overview of the business organization sponsoring the development of this product. This overview
should include the business's mission statement and its organizational objectives or goals.
System Description
In this the current system and its problems are described. The goals of the proposed system are described in
business terms along with an overview of the proposed system. The characteristics of the user are documented
in terms of familiarity with computerize system and automation and finally all assumptions on which the SRS
depends are listed.
 Product-Functions
Describes the general functionality of the product.
 Similar-System-Information
Describes the relationship of this product with any other products. Specifies if this product is intended to be
stand-alone, or else used as a component of a larger product. If the latter, this section discusses the relationship
of this product to the larger product.
 User-Characteristics
Describes the features of the user community, including their expected expertise with software systems and the
application domain.
 User-Problem-Statement
This section describes the essential problem(s) currently confronted by the user community.
 User-Objectives
This section describes the set of objectives and requirements for the system from the user's perspective. It may
include a "wish list" of desirable characteristics, along with more feasible solutions that are in line with the
business objectives.
62
 General-Constraints
Lists general constraints placed upon the design team, including speed requirements, industry protocols,
hardware platforms, and so forth.
Functional Requirements
This starts with a description of how the system is partitioned into modules (or subsystems). Further more each
module is described in terms of detailed requirements that the module needs to satisfy. The functional
requirements may be explained with the help of diagrams, use cases, schematics, charts and layouts. The
structure of this content would also depend on the modeling technique used during the requirements analysis
stage. How each module satisfies the stated goals is also documented at the end of the functional description of
each module. Small system may not be partitioned into modules.
This section lists the functional requirements in ranked order. Functional requirements describes the possible
effects of a software system, in other words, what the system must accomplish. Other kinds of requirements
(such as interface requirements, performance requirements, or reliability requirements) describe how the system
accomplishes its functional requirements.
Non-Functional Requirements
Non-functional requirements are characteristics of system to be achieved that are not related to the functionality.
Non-functional requirements define the system properties and constraints and also contain system “Quality”
attributes. Non-functional requirements should be stated separately from the functional requirements so that the
users can confirm during the requirements verification stage, the designers can focus on achieving these
requirements and testers can specifically conduct focused tests to confirm the achievement of the non functional
requirements.
This content of the SRS document further consist of the sub-contents which are described below:
Performance: - Performance or speed requirements are typically expressed as “processed transactions per
second” or “response time from the system for a user event” or “screen refresh time” or a combination of these.
Resource Utilization Efficiency: - this is a measure of how efficiently the system utilizes the CPU, the RAM,
and communications bandwidth and disk space.
Security: - security is the ability of the system to protect its functions and data from access, damage and
misuse.
63
Safety: - Safety requirements are those that are concerned with possible loss, damage, or harm that could result
from the use of the system.
Capacity: - This is the volume of transactions and the volume of data that the system will support, giving due
consideration to future increase/decrease in the volume.
Interfaces: - The other known and unknown systems that our system must interface with and the types of
interface that shall operate.
Availability: - Availability is the requirement for the system to be functional and operating during a specified
period.
Reliability: - Reliability is the characteristic of a system that increase its ability to execute without failure for a
longer duration. A system’s reliability can be measured in one or more of the following ways:
 Mean time to failure (MTTF). MTTF is the average time that a system operates before
encountering a failure. Reliable systems have a large MTTF.
 Average defects reported in a time period.
Accuracy: - The accuracy of the information stored and processing done needs to be specified. This can be
done in terms of allowed “margin of error”.
Reusability: - Many software projects have an additional goal of building a system whose component can
easily be modified and ported to other systems with no or minimal modifications. This increases the discipline
required in creating modular, reusable software much beyond the need of the system being developed.
Ease of Use: - An easy to use system results in (1) reduced training time (2) reduced time to perform user
operations. Some of the features put in to satisfy the first goal might result in deterioration of the second goal.
Interoperability: - Interoperability is the characteristics of the system that allows it to exchange data or
services with other systems.
Portability: - System designed on one plate form will need to be ported to other plate forms due to changes in
technology or need for handling larger volumes or increasing features and functionality.
Privacy: - This is closely related to the security requirements. In many countries data acquire through one
channel cannot be used for other purposes without explicit permission. In such cases privacy requirements need
to be stated as non functional requirements.
Expandability: - Expandability is the degree to which architectural, data or procedural design can be extended.
Maintainability: - Higher maintainability increases the speed with which the developers/maintainers make an
enhancement or fix a defect in the system. High maintainability is one of the ways to increase the availability of
the system and also essential for system that are likely to undergo frequent modification.
64
Testability: - Increased testability ensures that new modules can be integrated and the whole system can be
tested with the ease. To improve testability, designers need to increase the modularity, programmers need to
reduce the cohesion and testers need to create the test work products so that focused testing can be performed
on specific areas of the system.
Interface Requirements
This section describes how the software interfaces with other software products or users for input or output.
Examples of such interfaces include library routines, token streams, shared memory, data streams, and so forth.
User Interfaces
Describes how this product interfaces with the user.
 GUI
Describes the graphical user interface if present.
 CLI
Describes the command-line interface if present.
 API
Describes the application programming interface, if present.
Hardware Interfaces
Describes interfaces to hardware devices.
Communications Interfaces
Describes network interfaces.
Software Interfaces
Describes any remaining software interfaces not included above.
Design Constraints
In this content of SRS should provide a description of the issues that are likely to limit or act as a constraint on
the designers. These could include:
 International, National and local Laws.
65
 Hardware limitations
 Interfaces to other systems.
 Audit requirements.
In some documentation the design constraints are included in the addition to the non-functional requirements.
Project Requirements
This content is treated as optional it may or may not be include in SRS depends upon the way of writing the
SRS means on which it is focusing. So here, many of the requirements for this project execution may be known
at this point in time. If known and not present in any document, they can be (optionally) specified in SRS. The
project requirements at this stage typically include the size, effort and cost estimates, high-level schedules and
the development plate form on which the system is to be developed. The acceptance criteria can also be
specified in this section.
Preliminary Schedule
This section provides an initial version of the project plan, including the major tasks to be accomplished, their
interdependencies, and their tentative start/stop dates. The plan also includes information on hardware,
software, and wetware resource requirements.
The project plan should be accompanied by one or more PERT or GANTT charts.
Preliminary Budget
This section provides an initial budget for the project, itemized by cost factor.
Appendices
Specify other useful information for understanding the requirements. All SRS documents should include at least
the following two appendices:
 Definitions, Acronyms, Abbreviations

Provides definitions of unfamiliar definitions, terms, and acronyms.
66
 References
Provides complete citations to all documents and meetings referenced or used in the preparation of this
document.
4.4 Importance Of Requirements Documentation

The documentation is important in every field, this is not only essential for the software development process if
you are considering the medical side the doctors are use to keep the record of their patients this is the
documentation for the patient’s record, the manuals which are provide by the company with each product that
they sale this is the documentation of that product, means the documentation describes the space for which it is
build, for what it will be used and how it will be used this is said to be the documentation. So here in the
software development process the documentation acts very much important role, in simple words we can say
that the documentation describes the scenario of the purpose of the whole system which will be build, the
document of any system highlights the requirements of the customer that what the customer actually wants?,
and it also shows the whole way of the implementation of the system means how the system will be
implemented what it will contain how it will work, the way how the end user will operate it means just like a
manual is said to be the documentation. As we mentioned earlier that the documentation is necessary in every
field either it is related to software or any other department such as medical etc. The physicians are use to make
the document of their patients and so through that record they can easily identify the previous reports means that
is said to be reusability in terms of software engineering, that thing also saves the time and cost to review and
manage the system, in those cases specially when the requirements of the customers are going to be change day
by day according to the market means the requirements are not freeze.
A significant portion of most software development efforts is devoted to documentation. In addition to

improving program quality, good documentation improves software usability and maintainability; these are very
important for reducing long-term software related expenses. Documentation can play a major positive role in
the software development process. Unfortunately, very often, the documentation is one of the final steps in
software development. If the documentation is written by the developers when the project is nearing
completion, the document is often useful to people who know the software well, but usually hard for others to
understand. Because of the complexity of mathematical models that are usually used in engineering and
scientific simulations, any way to make requirements documentation easier to understand and use during
software development could dramatically reduce the number of errors found in such software.
67
If the documentation is well written with a particular format then that is very much use full for further phases or
stages which are incoming after that, such as the developer can easily review the system, the users can
understand what they actually expected from the system, the analyst can easily know what the user’s need that
have to be build etc. so after that the complexity to develop the system will reduce.
4.5 Summary
Documentation is the descriptive information (e-g hardcopy manuals, online help files, web sites) that portrays
the use and/or operation of the system. documentation describes the space for which it is build, for what it will
be used and how the particular system will be used by the users. The requirements document usually called the
software requirements specification (SRS). The software requirements specification (SRS) is produced at the
end of the elicitation and analysis tasks. Documentation of any system describes the purpose and
implementation requirements of the system. Further the contents are the major part of the documentation means
the document is fully depend on what the document actually contains.
A “good” SRS document has the following characteristics: (1) Completeness (2) Clarity (3) Correctness (4)
Consistency (5) Modifiability (6)Traceability (7) Feasibility (8) Testability.
The SRS template should be selected or defined at the start of the requirements elicitation activities, so that the
contents of the documents evolve and buildup as the requirements elicitation and analysis activities progress. A
significant portion of most software development efforts is devoted to documentation. In addition to improving
program quality, good documentation improves software usability and maintainability.
68
Chapter#05: Requirements Review
CHAPTTER # 05
REQUIREMENTS REVIEW
5.1 Requirements Review : An Overview
Requirements review is an activity after elicitation, analysis and documentation. This activity is also known as
“Requirements Verification” and states that:
“Verification ensures that the requirements conform to the characteristics of the
excellent requirement statements (complete, correct, feasible, necessary, prioritized, unambiguous, verifiable)
and of excellent requirements specification (complete, consistent, modifiable, traceable)”
For maximum effectiveness, review and verification should not be treated as a discrete activity to be done only
at the end of the preparation of the SRS. Review should be treated as a continuous activity that is threaded into
the elicitation, analysis, modeling and documentation with a formal phase end review scheduled after the SRS
document is ready. The requirements review is the requirements assurance activity, which assures that:
 Are the requirements complete?

 Are the requirements concise?
 Are the requirements correct?
 Are the requirements consistent?
 Are the requirements realistic?
 Is the requirement needed by the customer?
 Are the requirements traceable?
5.1.1 Continuous Review
Due to the problems of requirements volatility, the software engineering discipline has developed a new
perspective, one that assumes that requirements cannot be captured right the first time. It was recognized that
several iterations may be necessary to define requirements accurately. One of the ways of reducing
requirements volatility is to verify early and often that the information gathered so far and the representation of
that information is consistent with the user’s needs and expectations. This repeated review is part of an
incremental approach to elicitation, which should also be interleaved with modeling/analysis and prototyping.
QFD (Quality function deployment) is useful technique for continuous review. QFD allows the “voice of the
customer” to be captured, and the proposed requirements of the system to be reviewed based on whether or not
81
Chapter # 05: Requirements Review
they reflect these expressed customer needs. QFD helps to identify user requirements that have not been
addressed by the analyst as well as analyst-proposed features that do not support any user requirements. In
addition to highlighting such omissions, QFD also documents requirements that are highly rated by the user and
have received little attention by the analyst-proposed features.
5.1.2 Phase-End Review
Once the SRS is built and ready according to the analysts, the document needs to undergo a formal review. As
the SRS is foundation for estimation, design and subsequent software engineering activities, extreme care
should be taken in conducting the review. Improper review can result in an incorrect or incomplete system or
subject the development team to a constant set of changes to requirements. As we know errors in requirements
are 100 to 500 times more expensive to fix in the operations phase as compare to finding and fixing in the
requirements phase. Requirements review currently is a manual process, which involves reviewers reading the
SRS and verifying that the SRS is complete, clear, correct, consistent, modifiable, traceable, feasible and
testable. Reviews may be conducted using any one of the various review methods. In one of the review method
called the walkthrough method, the authors “walk” the reviewers through the proposed system, explaining each
requirement. The review team members raise issues, which are recorded. The most formal review method used
in the software development field is the “software inspection”. The inspection process comprises six distinct
steps -------- planning, overview, individual preparation, inspection meeting, rework and follow-up. During the
inspection meeting roles are assigned to each review team member.
70
The review may be held at multiple levels, staring with a high level review and ending with a detailed review.
The review needs to include participation from the view point of all stakeholders. This includes the sponsor of
the system, the customer, the various groups of the end users, the analysts, the project mangers and software
developers who will use the SRS downstream in the software lifecycle. Every issue (comment, defect, change
suggested, etc) needs to be documented and every issue needs to be addressed and “closed”. Once all the issues
raised are closed the SRS needs to be “signed-off” by the developer representative and the customer
representative.
5.2 Requirements Sign-Off

A sign-off by the representatives of the customer, the users and development team marks the end of the
requirements definition activities and the start of the requirements management activities. It is important that all
signatories understand what the sign-off means and avoid the typical pitfalls associated with sign-off.
 Meaning less formality Many customer representatives treat the sign-off as a meaning
less ritual. Some customer representative are also encouraged to form this impression by the developers with
statements like “our internal ISO procedures will not let us start the design without your formal sign-off, please
sign it, you may read and review it later.”
71
 Cast In Stone On the other hand some customer representatives are afraid to sign-off
the requirements as they believe (some times with justification) that the developers will stonewall any future
changes with statements like “you should have told us before you signed-off”.
The act of sign-off should be treated as a milestone in the project where the requirements are “base lined” and
that future changes to the requirements can be made through a well defined, control change management
process.
5.3 Requirements Review Process
 Plan review
The review team is selected and a time and place for the review meeting is chosen.
 Distribute documents
The requirements document is distributed to the review team members.
 Prepare for review
Individual reviewers read the requirements to find conflicts, omissions, inconsistencies, deviations from
standards and other problems.
 Hold review meeting
Individual comments and problems are discussed and a set of actions to address the problems is agreed.
 Follow-up actions
The chair of the review checks that the agreed actions have been carried out.
 Revise document
The requirements document is revised to reflect the agreed actions. At this stage, it may be accepted or it may
be re-reviewed
72
5.4 Perform Requirements Review & Its Outcome

Perform Requirements review to make sure your requirement describe completely how the User wants his
system to interact with the environment.
See if the requirements generated answers issues like:
a) Physical environment where the system is to function
b) Interfaces designed to format data or medium that data must use.
c) Human User factors like skill levels and training required of the user.
d) Functionality of what and when will the system do and whether there are constraints on execution
speed, response time or throughput.
e) Security issues like access provided to users and backup available.
f) Resources allocated to build use and maintain the system.
g) Quality assurance requirements for reliability, availability and maintainability.
The requirements have been developed up to this point with a steady stream of input and modification from
both the project team and the client. Therefore, the requirements are probably in a state where they could be
approved by the sponsor. However, there is one more final check that the project team may choose to schedule -
a Requirements Review Meeting. This meeting could include clients and team members, as well as individuals
that have a specific specialty in ensuring that the requirements are well worded and complete. These specialists
can provide a final quality review on the Business Requirements Report.
The Requirements Review Meeting is a final chance to verify that the requirements are in good shape to guide
the rest of the project lifecycle. The purpose is to try to catch any remaining requirements that are incomplete,
vague, untestable, etc. One of the most important parts of planning the meeting is to determine the participants.
The meeting should include knowledgeable clients and team members. The meeting may also include the
requirements specialists. If they participate, the specialists will focus on the format and the wording of the
requirements since they will not always understand the business content. However, if they do have questions on
the nature of a requirement, the project team and client must be able to explain it. The final Business
Requirements Report should also be circulated ahead of time so that the meeting can focus on questions and
potential problems, and not on just reading each requirement for the first time at the meeting. During the
meeting, the requirements are quickly scanned, and discussion takes place on any requirement where attendees
have questions or concerns. After a quick discussion, the requirement is modified or left alone. At this point, it
is important to try not to change the content and meaning of the requirement. You are just trying to change the
wording to make the meaning of the requirement clearer. If the meeting results in changing the content of a
73
requirement, the specific requirement may need to be circulated back to interested stakeholders for a final
review.
You can use the Requirements Review Checklist to shape the overall review meeting. After the review, final
modifications are made to the Business Requirements Report, and it is ready for final approval.
Outcome:
• The result of the requirements review should be the list of requirements.

• This list is used to establish the design of the application.
• The list is also used to establish the plan for testing the finished application. (Acceptance tests).
• These list of requirements is use to verify that either the proposed system is according to the
user needs or requirements which the user has already mentioned in the elicitation stage.
• It is use to verify that the requirements are complete, consistent, and correct enough to support
the next incoming phase.
5.5 Summary
Requirements review is an activity after elicitation, analysis and documentation. This activity is also known as
“Requirements Verification”. The requirements review is the requirements assurance activity. During the
requirements review activity if any problems of requirements volatility, the software engineering discipline has
developed a new perspective to avoid the requirements volatility which is the continuous review. In that we
simply do the review until all the requirements have been reviewed which we have gathered. Once the SRS is
built and ready according to the analysts, the document needs to undergo a review that is said to be the phase
end review. A sign-off by the representatives of the customer, the users and development team marks the end of
the requirements definition activities and the start of the requirements management activities.
The SSR is conducted when requirements have been sufficiently defined to evaluate the contractor's
responsiveness to and interpretation of the system, segment, or prime item level requirements.
This review is used to determine initial direction and progress of the system and complete training system
configuration. The review should focus on the completeness of the system requirements in terms of the
identification of complete requirements at the system level. The output of the system requirements review
(SRR) will be the : (1)Review Report (2)Review Checklist.
74
Perform Requirements review to make sure your requirement describe completely how the User wants his
system to interact with the environment. The result or the outcome of the requirements review should be the list
of requirements.
75
Chapter#07: Requirements Traceability
CHAPTER # 06
REQUIREMENTS CHANGE MANAGEMENT
6.1 Requirements Management: An Overview
Requirements Management is:
“ A process that establishes and maintains agreement between the customer and the project team on the
changing requirements of the system.”
Requirements Management is the process that enables system users, developers, Program Managers and
Test analyst to establish a common understanding of the system under development and assures that
business requirements under development are communicated in a clear manner. The RM process supports
the creation and maintenance of requirements documentation. These documents provide the community
with written information related to specific systems. Once these documents are produced the RM team can
review the requirement information for clarity, consistency, testability, completeness, and accuracy.
Requirements management is a process which supports other requirements engineering activities and is carried
out in parallel with them.
The principal concerns of requirements management are:
 managing changes to agreed requirements

 managing the relationships between requirements
 managing dependencies between the requirements doc and other doc produced during the
systems and software engineering process.
Hurried requirements gathering, analysis, documentation, review and sign-off can give rise to an unmanageable
set of changes thereafter. So one of the first steps of requirements management is to confirm that all the
previous related steps have been performed systematically. Secondly, the SRS document needs to be made as
modifiable as possible.
Requirements management is a new term which has been rapidly adopted by industry. It is the activity
concerned with the effective control of information related to system requirements and in particular the
100
Chapter # 07: Requirements Traceability
preservation of the integrity of that information for the life of the system and with respect to changes in the
system and its environment. The purpose of Requirements Management is to establish a common understanding
between the customer and the software project of the customer's requirements that will be addressed by the
software project.
Requirements Management involves establishing and maintaining an agreement with the customer on the
requirements for the software project. This agreement is referred to as the "system requirements allocated to the
software."
6.2 Requirements Management Plan
A requirements management plan is a component of the project management plan. Generally, the purpose of
RM is to ensure customer and developer have a common understanding of what the requirements for an
undertaking are. Several subordinate goals must be met for this to take place: in particular, requirements must
be of good quality and change must be controlled. The plan documents how these goals will be achieved.
Depending on your project standards, a variety of sections might be included in your RM plan. These sections
are discussed below:
1. Overview
This plan documents the Requirements Management processes and procedures to be used by the software
engineering team during the planning and implementation. This Plan defines how requirements will be
recorded; how requirements will be modified; and how requirements will be reconciled for final delivery of the
product.
2. Objectives
 Identify scope of what is managed.

 Identify Roles and Responsibilities of those involved in this management process.
 Describe the processes and procedures to be used during this management process.
 Identify the tools to be used.
3. Identification of Requirements Scope
This Plan sets out the processes and procedures to be used during the planning and implementation
77
4. Roles and Responsibilities
This section of Requirements management focuses on the persons involved in the Requirements Management
process.
4.1 Program Manager
The Program Manager is responsible for working with the customer to identify all requirements; is responsible
for submitting the customer's requirements to the Configuration Control Board for analysis and impact; is
responsible for communicating requirements impact to the customer; is responsible for negotiating requirements
modification when needed; and is responsible for delivery of the Test Analysis Report to the customer.
4.2 Configuration Manager (CM)
The CM is responsible for maintaining a matrix of all customer approved requirements; is responsible for
oversight of the requirements change control process; is responsible for applying changes to requirements
matrix; is responsible for maintaining the modification history of requirements.
4.3 Customer
The customer is responsible for defining and approving all requirements, and all modification to requirements.
4.4 QA/Test Manager
The QA/Test Manager is responsible for verifying that the delivered product satisfies the approved
requirements; is responsible for documenting the results of the requirements verification in a Test Analysis
Report.
4.5 Configuration Control Board (CCB)
The CCB, which is composed of all members of the software Team, is responsible for analyzing and evaluating
requirements for feasibility and impact to the project.
5. Processes and Procedures
This section describes what will be the processes and the procedures used to manage the requirements by the
requirements management team
5.1 Identification of Requirements

78
The Program Manager will confer with the customer to identify the structure of the delivered product, the
desired functionality of the product, and any performance issues. The Program Manager will present the
customer's requirements to the CCB for feasibility evaluation. The Program Manager will meet with the
customer to review the CCB's findings and negotiate any changes to requirements as a result of the CCB's
findings. The Program Manager will obtain the customer's approval for the requirements to be implemented.
5.2 Recording Requirements
The Program Manager will deliver to CM the requirements approved by the customer. CM will number and
enter each requirement into a requirements tracking matrix. CM will keep a project requirements file containing
documentation of customer approved requirements, and customer approved modifications to requirements.
5.3 Modification of Requirements
The Program Manager will receive direction from the customer to modify a requirement. The Program Manager
will present the request to the CCB for feasibility analysis and project impact. Program Manager will inform the
customer of project impact before modifications are implemented. CM will incorporate the approved
requirement modification into the requirements tracking matrix, and add the modification request to the
Requirements Project File. Approved modification will then be implemented by the project team.
Requirement modification requests must be present to the CCB for analysis. If the CCB agrees to the
modification request, the Program Manager will present request to the customer. If the modification is approved
by the customer, CM will incorporate the modification into the requirements tracking matrix, and a record of
the modification approval will be added to the Requirements Project File. The modification will then be
implemented by the project team.
5.4 Reconciling Requirements for Final Product Delivery
The Testing Manager will use the requirements tracking matrix to verify that all approved requirements have
been met. The QA/Test Manager will compile a brief Test Analysis Report to address the products conformity
to all approved requirements. The Program Manager will present the Test Analysis Report to the customer with
the delivery of the product. The QA/Test Manager will give a copy of the Test Analysis Report to CM for
inclusion in the Requirements Project File.
79
6. Requirements Management Tools
The requirements management team uses two main tools 1) Requirements Tracking Matrix and 2)
Requirements Project File. The requirements tracking matrix can be done by using the Microsoft Excel, and the
paper file is use for the requirements project file while managing the requirements.
7. Schedule
This section of RM plan gives the schedule , means when the particular activity has been performed it shows the
start date and end dates & time for each activity performed by the RM team. The activities can be Brainstorm
Requirements, Deliver Draft SRS, Update SRS based on comments, Update SRS for Preliminary Design
Review, Update SRS for Critical Design Review, Final update for Functional Acceptance Testing etc.
6.3 Requirements Change Management
This involves systematic handling of changes to agreed requirements (SRS) during the course of project. During
the processes of requirements engineering, system development and operation, new requirements emerge and
existing requirements change. These changing requirements must be managed to ensure that the quality of the
requirements is maintained. The impact of changes must be understood.
You should define policies for managing changes to requirements which set out how changes are formally
proposed, analyzed and reviewed. Accepted changes are then implemented to create a new version of the
requirements documentation.
Change management policies are concerned with the:
 Procedures
 Processes
 Standards
which are used to manage changes to system requirements.
Change management policies mean that similar information is collected for each proposed change and that
overall judgments are made about the costs and benefits. It should define the following:
80
 The change request process and the information required to process each change request.
 The process used to analyze the impact and costs of change, and the associated traceability
information.
 The membership of the body which formally considers change requests
 The software support (if any) for the change control process. A DB can be used to store all
change requests, their status and how they have been implemented.
6.3.1 Why Do Requirements Change
If it were possible to define a set of requirements for a system once and only once, life would be much simpler,
and there would be no need for this chapter. We could simply create a perfect Vision document, software
requirements specification, and use-case model; freeze them for the duration of the development effort; and then
declare everything past that point to be the responsibility of the maintenance team. Alas, things don't work that
way; they never did in the past, and even with a more systematic approach to requirement management, they
will not work that way in the future.
There are several reasons for the inevitability of changes through the requirements. Some of these reasons are
internal factors and may be under our control, but many of them are external factors and are outside control of
the developers and the users.
6.3.1.1 External Factors
External factors are those change agents over which the project team has no control. No matter how we manage
them, we must prepare our selves technically, emotionally and managerially to be able to address these changes
as part of the “normal course of software development activity”. Changes occur because:
 There was a change to the problem that we were attempting to solve with the new system.
Perhaps a change occurs in the economy, in government in regulations, or in the market place and consumer
preferences.
 The users changed their minds or their perceptions about what they wanted the system to do.
For example if the user who described the requirements for the system leaves the customer’s team, the
replacement is likely to be someone with an entirely different set of opinions and perceptions.
 The external environment has changed, which creates new constraints and / or new
opportunities. One of the most obvious examples of environmental change is the ongoing improvements in
computer hardware and software systems.
81
6.3.1.2 Internal Factors
In addition to the external factors, a number of internal factors can contribute to the problem of change.
 We failed to ask the right people the right questions at the right time during the initial
requirement gathering effort. If our process does not include all stakeholders or if we do not ask all the right
questions of them, we contribute to the change problem by simply not understanding the true requirements for
the system.
 We failed to create a practical process to help manage changes to the requirements that will
normally have happened on an incremental basis. We may have attempted to “freeze” the requirements, thus,
the “latent”, necessary changes piled up until they created such pressure that they inevitably exploded in the
face of developers and the users, causing rework and stress. Or, perhaps, we created no change process at all,
thereby allowing, or even encouraging people to change whatever they wished whenever they wished. In this
case, at some point, almost everything is change, and you can no longer “see the forest for the trees”.
6.4 Requirements Change Management Process
Clearly, given the fact that change is a natural part of the process and that change will come from both external
and internal sources, a process for managing change is needed. Such a process puts the team in control so that it
can effectively discover change, perform impact analysis, and incorporate those changes that are deemed to be
both necessary and acceptable into the system in a systematic manner.
Since changes to requirements are inevitable, we may as well prepare ourselves to handle changes using a well
defined process. A simple change management process which can be used to handle changes to requirements is
depicted in figure 6.1. The change request form (CRF) and the change control board (CCB) are two key entities
of the change management process.
82
The important steps in the Change Management Process are as follows:
Initiation: - A change to the requirements is initiated by filling up the relevant parts of the CRF. A change to
requirements must always be expressed as a change to SRS. As part of the CRF initiation, the initiator describes
the change required with respect to what
is documented in SRS, the initiator can be any of the stakeholders. The initiator also describes why such a
change is required to the system, what benefits are expected with the change or what difficulties will be faced
without the change and how important the change is from initiator’s point of view.
Impact Analysis: - The initiator hands over the CRF to a designated person in the project. This person is often
called Configuration Controller (CC) or configuration manager. The CC along with the project manager, hand
over the CRF to various members of the project team and other stakeholders to evaluate the proposed change
from various perspectives, e.g, technical feasibility, additional resources, etc.
Evaluation: - The CC collects the impact’s analysis and calls for a meeting of the CCB. The CCB typically
comprises the project manager, the CC and the senior designers from the development team and a similar set of
persons representing the customers and end-users. The CCB typically meets periodically (once a week to once a
83
month) and decides on the disposition of the pending CRFs where the impact analysis is complete. The CCB
may take one of the following decisions for each CRF presented:
 Approved for change.
 Rejected.
 Partially Approved.
 Keep Pending For next Activity CCB Meeting.
 Perform further impact analysis.
Planning: - If a CRF is fully or partially approved, the CC fills up the implementation plan for implementing
the CRF. This implementation plan includes the “base lined” items that will need to be changed, what versions
will be changed and what quality control steps will be taken on each item that will be changed.
Execution: - The changes are made according to the implementation plan. This includes all the quality control
steps that were planned in the implementation plan for the CRF.
Closing: - The CRF is marked as closed after verifying that all changes that were required have been made.
As can be seen above, the CCB is the group that decides to approve or reject proposed changes given by the
CRF for a project. On small projects the CCB comprises a representative from the customer and another
representative from the development project (project leader). On a very large project the CCB members may
include others such as end-user representatives, CC and testing-in-incharge. The CC is responsible to ensure
that changes to requirements document is not made unless the supporting CRF is approved by the CCB. Once
the Required change is made, The CC is responsible to ensure that only the approved changes have been made.
6.5 Summary
Requirements Management is: “A process that establishes and maintains agreement between the customer and
the project team on the changing requirements of the system.”. Requirements Management involves
establishing and maintaining an agreement with the customer on the requirements for the software project.
The Requirements Management plan documents how the goals such as good quality, control of change
management etc, will be achieved. Depending on your project standards, a variety of sections might be included
in your RM plan.
Requirements change management involves systematic handling of changes to agreed requirements (SRS)
during the course of project. The Requirements are commonly change either by the internal or the external
factors or by both. Requirements have possibility to change due to internal factors, when we failed to ask the
84
right people the right questions at the right time during the initial requirement gathering effort. External factors
are those change agents over which the project team has no control.
85
CHAPTER # 07
REQUIREMENTS TRACABILITY
7.1 Requirements Traceability: An Overview
Requirements traceability is at the heart of requirements management. Requirements traceability (abbreviated,
RT) refers to the ability to describe and follow the life of a requirement in both a forwards and backwards
direction (ie from its origins, through its development and specification, to its subsequent deployment and use,
and through periods of ongoing refinement and iteration in any of these phases).
The requirements traceability can be more simply described as:
“The ability to describe and follow requirements in both forward and backward direction”.
Requirements traceability enables the software engineer to focus on the following:

 Make a list of the system requirements.
 Write the user manual for the system in the form of use cases.
 Make sure you can trace every piece of your design to at least one user requirement.
 Make sure you can trace every requirement to the point at which its satisfied within your
design.
 Trace your design back to your requirements as you review the design during your
critical design review.
Requirement Traceability is an effective technique, which also supports the verification activity. Software
requirements are traced from one or more product features identified in the early stages of SRS. Traceability
information is information which helps you assess the impact of requirements change.
Traceability information allows answering:
 What is the impact of changing a requirement?

 Where is a requirement implemented?
 Are all requirements allocated?
 What need is addressed by a requirement?
 Is this requirement necessary?
86
 What design decisions affect the implementation of a requirement?

 Why is the design implemented this way and what were the other alternatives?
 Is the implementation compliant with the requirements?
 Is this design element necessary?
 How do I interpret this requirement?
During design phase requirements traceability allows to keep track of what happens when change request is
implemented before a system is redesigned. Traceability can also give information about the justifications,
important decisions and assumptions behind requirements.
Traceability is primarily to help assess the impact of requirements change (tracing forwards to design), and to
demonstrate complete satisfaction of requirements (tracing backwards from design). The forward and
backward tracing types are further categorized as follows:
Backward-from traceability Links requirements to their sources in other documents or people
Forward-from traceability Links requirements to the design and implementation components
Backward-to traceability Links design and implementation components backs to requirements
Forward-to traceability Links other documents (which may have preceded the requirements document) to
relevant requirements.
The requirements traceability is categorized as pre and post requirements traceability. Pre-requirements
traceability (pre-RT) refers to the ability to describe and follow those aspects of a requirement's life prior to its
inclusion in the RS in both a forwards and backwards direction (i.e., requirements production and refinement).
Post-requirements traceability (post-RT) refers to the ability to describe and follow those aspects of a
requirement's life that result from its inclusion in the
87
RS in both a forwards and backwards direction (i.e., requirements deployment and use).
Excessive traceability results in an unwieldy tangle of unmanageable links, and provides little support to
developers. Lack of traceability results in projects delivered late and over-budget, and deterioration in the
overall quality of the system.
7.2 Types of Requirements Traceability
1) Requirements-Sources Traceability
Links the requirement and the people or documents which specified the requirement
2) Requirements-Rationale Traceability
Links the requirement with a description of why that requirement has been specified.
3) Requirements-Requirements Traceability
Links requirements with other requirements which are, in some way, dependent on them. This should be a two-
way link (dependants and is-dependent on).
4) Requirements-Architecture Traceability
Links requirements with the sub-systems where these requirements are implemented. This is particularly
important where sub-systems are being developed by different sub-contractors.
5) Requirements-Design Traceability
Links requirements with specific hardware or software components in the system which is used to implement
the requirement.
6) Requirements-Interface Traceability
Links requirements with the interfaces of external systems which are used in the provision of the requirements.
7.3 Requirements Traceability Techniques

There are three common techniques are used to trace the requirements which are:
1) Traceability Tables,
2) Traceability Lists.
3) Automated traceability links
From the above types, the traceability tables and the traceability lists are most widely used while tracing the
requirements while the third technique is some times omitted. These techniques are discussed below in detail.
7.3.1 Traceability Tables

Traceability tables show the relationships between requirements or between requirements and design
components. Requirements are listed along the horizontal and vertical axes and relationships between
88
requirements are marked in the table cells. Traceability tables for showing requirements dependencies should be
defined with requirement numbers used to label the rows and columns of the table.
7.3.2 Traceability Lists

If a relatively small number of requirements have to be managed (up to 250, say), traceability tables can be
implemented using a spreadsheet. Traceability tables become more of a problem when there are hundreds or
thousands of requirements as the tables become large and sparsely populated. A simplified form of traceability
table may be used where, along with each requirement description, one or more lists of the identifiers of related
requirements are maintained. Traceability lists are simple lists of relationships which can be implemented as
text or as simple tables.
7.3.3 Automated Traceability Links
Here in this technique of traceability, the requirements are maintained in a database and traceability links are
included as fields in the DB record.
7.4 Traceability Polices
Traceability policies define what and how traceability information should be maintained.
Traceability policies may include:
 The traceability information which should be maintained.
89
 Techniques, such as traceability matrices, which should be used for maintaining traceability.
 A description of when the traceability information should be collected during the requirements
engineering and system development processes.
 The roles of the people, such as the traceability manager, who are responsible for maintaining
the traceability information, should also be defined.
 A description of how to handle and document policy exceptions.
 The process of managing traceability information.
7.5 Maintaining Requirements Traceability
Requirements Traceability is the means of tracking down each individual requirement in the SRS to the various
work products created during the course of the project. To provide traceability the SRS needs to be organized in
such a manner that each unitary requirement is uniquely identified using labels or numbers.
As downstream work products are created in the development project a traceability cross-0refrence is provided
from each uniquely identified requirement to each design feature in the design document. Similarly the SRS is
cross-referenced to the high level test plans (e.g., Acceptance test plan and System test plan). The cross-
reference provides both the forward traceability and the backward traceability.
Advantages of Requirements Traceability are:
 It helps to confirm that all requirements are designed and tested. It often happens that certain
requirements get missed out from the design or test plans due to oversight. The cross-reference identifies such
oversights immediately.
 It helps to confirm that every feature in downstream work products supports a requirement.
Designers and developers some times add features some of which may not support any requirement. Such
features are a waste of energy and effort. The traceability cross-reference identifies such unnecessary design
features.
 Impact analysis for change management can be performed more effectively. The traceability
cross-reference can be used to identify all impacted items and changes can be made consistently across all work
products.
7.6 Summary
The requirements traceability described as: “The ability to describe and follow requirements in both forward
and backward direction”. Requirement Traceability is an effective technique, which also supports the
verification activity. During design phase requirements traceability allows to keep track of what happens when
change request is implemented before a system is redesigned.
90
Traceability is primarily to help assess the impact of requirements change (tracing forwards to design), and to
demonstrate complete satisfaction of requirements (tracing backwards from design).
There are three common techniques are used to trace the requirements which are: 1)Traceability Tables, 2)
Traceability Lists, and, 3) Automated traceability links.
Traceability policies define what and how traceability information should be maintained.
91
Chapter#08: Applying Requirements Engineering On MCSC
CHAPTER # 08
APPLYING REQUIREMENTS ENGINEERING ON MCSC
8.1 History Of Mobilink’s Systems
As we know that communication is a vast field, nowadays it is common to have mobiles un each and every
hand. As the use of mobiles is growing day by day so there are so many problems regarding their usage. In the
early days these customer’s related problems were very much difficult to handle manually so the Mobilink’s
company decided to develop such a system which should be able to handle the customer’s complains (queries of
customers) so they developed the system called CSS (Customer Service System), it was the initial version
developed by Asif in 1999. That system having low capacity of storage and was very much limited to handle the
complains regarding customers.
The major disadvantage of CSS system was that it didn’t support online services, and that system was only
running at head office. All the Franchises of Mobilink handle the queries of customers manually and than
concerned with their head office.
As time passed they decided that Franchises must also be able to handle subscriber’s complains so they revised
the existing system and that revised system is called as iCrM (internet Customer R/S Management System)
develop in 2002. Now in these days the iCrM is running in all Franchises of Mobilink. Now the franchises can
be able to handle the customer complains at their own spot.
8.2 Drawbacks In Existing System (iCrM)
there are so many flaws in the existing system (iCrM) such as:
 iCrM don’t directly communicates to the main server, there is an intermediate system
between the system running in Franchise and server in head office.
 The iCrM doesn’t give the facility to get the information regarding your balance in last
loaded card, and also doesn’t give the info about diverted calls dialed no lists.
 The operator of the iCrM is only able to solve those queries of customer whose activities
are built in the system.
 The major drawback of iCrm is that it can’t be enhanced, means if you want to add more
options you can’t do that.
 The system has less storage capacity.
 iCrM is very limited that is not able to handle complex type of queries.
 It can’t handle lots of customers at a time.
 The system is not able to activate, deactivate the pin code of SIM.
140
Chapter # 08: Applying Requirements Engineering On MCSC
 The processing of system is very slow due to intermediate system that’s why the response
time is very high.
8.3 SRS Of Proposed System (iCrM2k5)
Mobilink Customer Service Center
Internet Customer Relationship Management System

(iCrM)
Software Requirements Specification

Document (SRS)
Revision History
Date Revision Description Author
1/12/1999 CSS (Customer Service Initial version it did not support online Asif Bawani
System) Services
1/6/2002 iCrM (Internet Customer Revised to support online services Asim
Relationship Management)
1. Introduction
1.1 Purpose
93
This is the software requirements specification for iCrM2K5. Its goal is to enhance the existing system (iCrM)
in such a way that it handles the customer queries & problems which occur in daily usage of Mobile
Communication.
1.2 Scope
 iCrM2K5 will support all customer queries online.
 The operator of the System handles the queries of customers by sending the request
online to their Head Office
 The operator of the system can view the subscriber’s information through subscriber
number (Cell No).
 The revised system will not only handle those queries option which are already built-in in
the system but it also give the facility to send any type of query to head office via mailing.
 The revised system will give the facility to add more options in the existing system such
as if the company is going to announce some packages to customers than that type of options can be
accommodate easily.
 iCrM2K5 will directly communicate with the head office servers without any
intermediate.
 The revised system will facilitate thrice more storage capacity than existing system.
1.3 References
 CSS System & its documentation
 iCrM System & its documentation
 website of mobilink GSM (www.mobilinkgsm.com)
94
2 Use-case Model Survey
Use-Case Name Description Actor(s)

Search Information This use-case searches the information about Operator
subscriber, jazz, scratch card, switch (connection),
balance ,dialed numbers and diverted calls
Create Activity This use-case creates the activities regarding the Operator
queries of the customer such as change of sim,
block on stolen and many more
View all Activities This use-case is used to show the activities Operator
which have been created today and previously
(weekly)
Pending Activities This use-case is used to show all those activities Operator
which are either canceled or still in process
(Planned)
Search Activity This use-case is used to search the information Operator
about the created activities that have been either
planned, canceled, completed or held
Change Password This use-case is used to change the login Operator / Owner
password of the system operator
Request Box This Use Case is used to send all types of
Complains, usually those activities which are not built-
in in the system
95
Dialed#info
Divertedcalls info
Balanceinfo
Subscriber info
Owner
JAZZinfo
Searchinfo
Connectioninfo
SearchActivity Scratchcardinfo
ViewAll Activities
Changeof SIM
PendingActivities
Blockonstolen
CreateActivity Restoration
Owner
JAZZRecreation
Request Box
Scratchcardblocking
ChangePassword
BlockVoluntarily
Changeof Ownership
JAZZUnsuspension
96
3 Actor Survey
Actors which interact with the iCrM2K5 are as follows
Actor Name Description
Operator This is the main actor of the system which performs all
activities regarding customers queries
Owner He has all rights, He monitor the overall system.
Owner can also work as an operator
Head Office Server It response to all the requests, which are sent by client side
(Operator/Owner)
4 Requirements
4.1 Functional Requirements
• FR1 Search Information
Through this option the operator will be able to search the information.
• FR1.1 Subscriber information
By this, the operator will be able to view the subscriber name, package plan, SIM number, NIC/Passport
number in the status of the subscriber to whom this connection is issued.
• FR1.1.1 PUKK Information
This option will show that either the pin code is activated or deactivated on the customer’s SIM; if the code is
activated then it will be appeared in the column of PUKK information otherwise the column will be empty.
• FR1.2 Connection Information
By this, the operator will be able to get the information such as switch ON date (it will show the date, when
the connection was issued), last update(It will show the first loaded card date) and Dealer code (It will show the
code who issued the connection)
• FR1.3 JAZZ Information
By this, the operator will be able to check the last recharge date (It will Show last loaded card time & date) ,
last recharge amount (It will show Amount that had been loaded last time), Scratch expiry date (It will show
the date on or before , consumer have to recharge his/her account ), Deactivation date (It will show the date
of last expire card with grace Period)
• FR1.4 Scratch Card Information
By this, the operator will be able to check that either the scratch card has
been loaded on which date and time through scratch card number and also
tells either this scratch card has been loaded in your SIM or NOT by
97
checking the subscriber no.
• FR1.5 Calls Information
By this operation, the operator will be able to check the current balance, dialed nos and diverted calls in last
loaded card.
• FR1.5.1 Balance Information
By this option, the operator will be able to check the current balance in last loaded card.
• FR1.5.2 Dialed Numbers Info
By this the operator will able to view the whole list of dialed numbers of last loaded card.
• FR1.5.3 Diverted calls Info
By this, the operator will be able to check that either user has diverted the calls in last loaded card and this
option will also the list of those numbers to whom the call was diverted.
• FR2 Create Activity
This option is used to create the activities regarding the complains of the customer which are built in the system.
These activities are created online.
• FR2.1 Change of SIM
By this activity, the operator will be able to issue a duplicate SIM in case of stolen or blocked on some charges.
• FR2.2 Block on stolen
By this activity, the operator will be able to block the SIM on the request of customer by checking the
NIC/Passport No.
• FR2.3 Change of ownership
By this activity, the operator will be able to change the ownership of the SIM.
• FR2.4 Block Voluntarily
By this activity the operator will be able to block SIM temporarily and Unblock on the request of the subscriber.
• FR2.5 Scratch Card Blocking
By this activity, the operator will be able to send the request to the server to block the scratch card
number in case if that card has been already loaded or defected.
• FR2.6 JAZZ un-suspension
If the subscriber has inputted the scratch card numbers 10 times and card is not loaded in the SIM than the card
will be suspended, so by this option the operator will be able to un-suspense the Card Number.
• FR2.7 Restoration
By this activity, the operator will be able to restore the SIM, if it has been blocked due to some reason.
• FR2.8 JAZZ Re-creation
98
By this activity the operator will be able to reissue the duplicate SIM, if SIM is expired due to some reason such
as card has not been loaded after the last date of grace period, on some cast.
• FR3 View all Activities
By this activity the operator will be able to view all the activities which have been created (Today or weekly).
• FR4 Pending Activities
By this option, the operator will be able to view all those activities which have been either canceled or still in
process.
• FR5 Search Activity
By this option, the operator will be able to search about the activities, Which were planned, canceled, completed
or held?
• FR6 Change Password
The operator will be able to change the login password of the terminal.
• FR7 Request Box

By this option the operator will be able to send all types of complains, usually those activities which are not
built-in the system. By this they will simply write the complains in the request box and upload it to the head
office server.
Non Functional Requirements

NFR1 Performance
• NFR1.1 System should send complains of the subscribers with in few seconds
• NFR1.2 System should get response from the server with-in 24 hours
• NFR1.3 System should facilitate thrice more storage capacity
• NFR1.4 System’s throughput will be high
NFR2 Reliability
• NFR2.1 iCrM2K5 operate as close to 100% reliable as possible.
• NFR2.2 The system must have no defects that can interfere with normal operation.
NFR3 Usability
• NFR3.1 Ease of use.
• NFR3.2 Flexible enough to accommodate the change.
99
NFR4 Supportability
• NFR4.1 The system must be completely documented
• NFR4.2 Training to the users of the system
5 Design Constraints
DC 1 The operator should send single request to the server at one time.
DC 2 The system must be developed by using VB6.0 and ASP.
DC 3 The revised system should be compatible to existing system.
DC 4 Minimal use of key board.
DC 5 It only handles the subscriber complains without information of finance and Stock.
DC 6 The user of the iCrM2K5 will not be allowed to create their new account, User-ID should be
assigned by the head office.
DC 7 The operator of the system should strictly authenticated by the server through connection-ID/
User-ID.
DC 8 The system will give the information about the subscriber, JAZZ, Switch etc only by the
subscriber no
6 Purchased Components
The complete system including processor, hard disk, mouse, monitor, .Motherboard, Ram etc
100
7.1 User Interface
101
102
103
104
105
106
107
108
109
110
8 Licensing Requirements
 All rights are reserved to the Mobilink GSM company
 iCrM2K5 is the registered trademark of Mobilink, so no one can use this name for their
products.
8.4 Benefits Of Proposed System (iCrM2k5)
After the implementation of proposed system, the Mobilink’s Franchises will get the following benefits:
 By the use of iCrM2k5 the operators will be able to handle any type of subscriber’s
complain although it is not built-in in the system. They simply send the request via the use to Request
Box.
 The iCrM2k5 will give the facility to record the current balance in the subscriber’s last
loaded card. Another benefit after the implementation of proposed system (iCrM2k5) will be, it will
give the Diverted Calls information i-e it will show those numbers to whom the call were diverted and
the time duration for which the call has been diverted. It will also show the amount which has been
deducted for each diverted call based on the Duration.
 The proposed system will also give the information of Dialed #s. by this information the
operator will be able to view the list of all those Numbers which the customer has dialed and also the
time duration of each dialed number and amount which had been deducted for each dialed call.
 The system will also give the Scratch Card Information. By this the operator will be able
to check that which card# is loaded in which SIM by simply inputting the 14 digit code.
 The revised system will be able to store more information than the existing system.
111
 The system will be able to send the request within minutes and receive the response
within 24 hours, because the proposed system will be able to communicate directly with the main
server.
 By the iCrM2k5 the operator of the system will be able to view , activate and deactivate
the Pin code of the SIM by using the PUKK information.
APPENDIX A
REFERENCE BOOKS
[1] Managing Software Requirement (A Unified Approach)

By Dean Leffingwell &
Don Windrig
[2] Software Requirements & Estimation

By Swapna Kishore &
Rajesh Naik
[3] Requirements Engineering

By E. Kazmierczak
[4] Software Engineering

By Roger S. Pressman
[5] Software Engineering

By Ian Somerville
[6] Object Oriented Software Engineering

By Eric J. Braude
[7] Applying UML & Patterns (An Introduction to Object – Oriented Analysis
& Design)
By Craig Larman
[8] Instant UML

By Pierre – Alain Muller (WROX)
112
113
Appendix A: Reference Books
APPENDIX B
WEB REFERENCES
1) Requirements Engineering: A Roadmap
http://www-dse.doc.ic.ac.uk/~ban/pubs/sotar.re.pdf
2) Requirements Engineering: A Good Practice Guide
http://www.amazon.com/exec/obidos/ASIN/0471974447/ - 84k-
http://www.satisfice.com/articles/reframing_requirements.pdf
3) Requirements Engineering Introduction
http://www.comp.lancs.ac.uk/computing/ resources/re/slides/Ch1intro.ppt –
http://www.ecommerce.ncsu.edu/studio/lectures/re_new.pdf -
http://www.dit.unitn.it/tropos/re04/slides/2-RE-intro.pdf -
4) Viewpoints for Requirements Elicitation: A practical approach ...
http://www.comp.lancs.ac.uk/computing/research/ cseg/projects/reaims/papers/practicalVPs.pdf
5) A Unified Model of Requirements Elicitation
http://www.cc.gatech.edu/classes/ AY2002/cs6300_fall/req1/Reqts.ppt -
6) Techniques for Requirements Elicitation: http://www.citeseer.ist.psu.edu/goguen93techniques.html - 27k -
7) Requirements Analysis – Characterisitics of Good Requirements ...
http:// www.catalyst.uq.edu.au/ designsurfer/good_requirements.PDF -
8) Requirements Analysis: http://www.faqs.org/faqs/software-eng/part3/section-11.html - 5k -
9) Requirements Analysis and Modeling
http://www.mitretek.org/home.nsf/ ServiceTools/RequirementsAnalysisModeling - 15k –
10) Writing Requirements Documentation for Multiple Audiences
http://www.mis.vanderbilt.edu/METHODOLOGY/ RequirementsDocumentation.doc
11) Agile Requirements Documentation
http://www.c2.com/cgi/wiki?AgileRequirementsDocumentation - 4k –
http://www.20Documentation/Requirements%20Documentation - 101k -
12) Requirements Change Management
http://www.hl7.org/Special/Committees/ claims/HIPAA_MOU_Change_Management
13) Software Requirements Change Management Strategy
http://www. resources.crmbuyer.com/20Change%20Management%20Strategy - 101k
14) Client Side and Client Based Change Management Software
http:// www.change-management-directory.com/ software/client-side.html - 7k –
15) Requirements Management Overview:
http:// www.teraquest.com/training/courses/ Requirementsmgt/Overview.pdf -
16) Requirements Tracing--An Overview: http://www.sei.cmu.edu/str/descriptions/reqtracing_body.html - 25k -
17) An Analysis of the Requirements Traceability: http:// www.cs.ucl.ac.uk/staff/A.Finkelstein/papers/rtprob.pdf -
140

SRE Complete Chapters

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

SRE Complete Chapters

Încărcat de

Drepturi de autor:

Formate disponibile

Chapter # 03: Requirements Analysis

Characteristics Of Requirements: - Requirements must be validated

 Are the requirements correct?

 Are the requirements consistent?

1.1.1: - Software Requirements: -

1.2: - Requirements Engineering: An Overview

Requirements engineering can be divided into two main set of activities:

Requirements Definition consists of:

1) Requirements Elicitation or gathering of requirements.

Requirements Management consists of:

1) Requirements Change Management: - This involves systematic handling of changes to agreed

1.3 : Importance Of Requirements Engineering: -

1.4 : Requirements Engineering Process: -

1.5 : Spiral Model of Requirements Engineering Process: -

1.6 : RE Process Maturity Model: -

REMM is a three level model.

RE process maturity model will:

 defined standards for requirements documents

1.7 : Requirements Engineering Life Cycle: -

Elicitation And Analysis

The Process activities in this phase are:

REMM is a three level model.

 Level 1 - Initial level,

2.1 Requirements Elicitation: An Overview

“You must get information out of clients’ minds

There are some important types of requirements elicitation which are :

 Provide the services of an existing system in a new environment

2.2 Requirements Elicitation Techniques

2.2.1 Traditional Techniques

The final set of questions focuses on the effectiveness of the meeting:

2.2.2 Group Elicitation

2.2.2.1 JAD (Joint Application Development)

2.2.2.2 RAD (Rapid Application Development)

1. To converge early toward a design acceptable to the customer

2.2.2.3 Requirements Workshop

A properly run requirements workshop has many benefits.

Preparing for the workshop

Brainstorming is the most important part of the workshop.

3. Set up the rules for the session. They should include

 Letting the leader have control.

 Looking for any answers that are repeated or similar.

2.2.5 Applying Use Case (Scenarios)

2.2.6 QFD (Quality function deployment)

QFD identifies three types of requirements:

2.2.7 CORE (Controlled Requirements Expressions )

Viewpoints considered in CORE include both functional viewpoints and non-functional

2.2.8 IBIS (Issue Based Information System)

2.2.9 FODA (Feature Oriented Domain Analysis)

The FODA methodology consists of three steps.

2.3 Requirements Elicitation Activities

2.3.1 Fact- Finding

The output from fact-finding includes:

2.3.2 Requirement Gathering

 Classifying wish lists according to functional, non-functional, environment, and design

3.1 Requirements Analysis : An Overview

3.2 Levels Or Categories Of Requirements Analysis

3.2.1 Customer Or C – Requirements

Road Map Of C- Requirements

There are various ways to express the C-requirements:

3.2.2 Detailed or D – Requirements

Road Map Of D – Requirements

3.2.2.1 Types Of D – Requirements

3.2.2.1.1 Functional Requirements