SRE Complete Chapters
-
Upload
azam-shaikh -
Category
Documents
-
view
229 -
download
0
Transcript of SRE Complete Chapters
-
8/7/2019 SRE Complete Chapters
1/114
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
-
8/7/2019 SRE Complete Chapters
2/114
Chapter # 03: Requirements Analysis
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
systems 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
-
8/7/2019 SRE Complete Chapters
3/114
-
8/7/2019 SRE Complete Chapters
4/114
Chapter # 03: Requirements Analysis
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
-
8/7/2019 SRE Complete Chapters
5/114
Chapter # 03: Requirements Analysis
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 towrite 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
http://www.threesl.com/pages/reference/requirements/audits.php#_ftn1http://www.threesl.com/pages/reference/requirements/audits.php#_ftn2http://www.threesl.com/pages/reference/requirements/audits.php#_ftn2http://www.threesl.com/pages/reference/requirements/audits.php#_ftn1 -
8/7/2019 SRE Complete Chapters
6/114
-
8/7/2019 SRE Complete Chapters
7/114
Chapter # 03: Requirements Analysis
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
-
8/7/2019 SRE Complete Chapters
8/114
Chapter # 03: Requirements Analysis
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
-
8/7/2019 SRE Complete Chapters
9/114
Chapter # 03: Requirements Analysis
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 isknown 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
-
8/7/2019 SRE Complete Chapters
10/114
Chapter # 03: Requirements Analysis
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 aconsistently 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
-
8/7/2019 SRE Complete Chapters
11/114
Chapter # 03: Requirements Analysis
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
-
8/7/2019 SRE Complete Chapters
12/114
Chapter # 03: Requirements Analysis
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. Thats 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.
RefinementThis 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
-
8/7/2019 SRE Complete Chapters
13/114
Chapter # 03: Requirements Analysis
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
-
8/7/2019 SRE Complete Chapters
14/114
Chapter # 03: Requirements Analysis
(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
-
8/7/2019 SRE Complete Chapters
15/114
Chapter # 03: Requirements Analysis
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 notwant 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
-
8/7/2019 SRE Complete Chapters
16/114
Chapter # 03: Requirements Analysis
Provide the services of an existing system in a new environment
Triggered by technology enabler or new market needs
2.2 Requirements Elicitation TechniquesBefore 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 thats 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 notbe 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
-
8/7/2019 SRE Complete Chapters
17/114
Chapter # 03: Requirements Analysis
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 users response to a question puzzles the interviewer, he or
17
-
8/7/2019 SRE Complete Chapters
18/114
Chapter # 03: Requirements Analysis
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
-
8/7/2019 SRE Complete Chapters
19/114
Chapter # 03: Requirements Analysis
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 thats 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
-
8/7/2019 SRE Complete Chapters
20/114
Chapter # 03: Requirements Analysis
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 builtin 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
http://www.webopedia.com/TERM/R/executable_file.htmlhttp://www.webopedia.com/TERM/R/executable_file.htmlhttp://www.webopedia.com/TERM/R/executable_file.html -
8/7/2019 SRE Complete Chapters
21/114
Chapter # 03: Requirements Analysis
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 stakeholdersof 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
-
8/7/2019 SRE Complete Chapters
22/114
Chapter # 03: Requirements Analysis
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 brainstormingis 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
-
8/7/2019 SRE Complete Chapters
23/114
Chapter # 03: Requirements Analysis
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 Interactionwith 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
-
8/7/2019 SRE Complete Chapters
24/114
Chapter # 03: Requirements Analysis
Active Storyboards Try to make the user to see a movie that hasnt 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 operationalscenario.
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
-
8/7/2019 SRE Complete Chapters
25/114
Chapter # 03: Requirements Analysis
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
-
8/7/2019 SRE Complete Chapters
26/114
Chapter # 03: Requirements Analysis
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-endedapproach), 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 actua
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
-
8/7/2019 SRE Complete Chapters
27/114
Chapter # 03: Requirements Analysis
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 functionalbehavior.
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
-
8/7/2019 SRE Complete Chapters
28/114
Chapter # 03: Requirements Analysis
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 customers 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
-
8/7/2019 SRE Complete Chapters
29/114
Chapter # 03: Requirements Analysis
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 viewpoin
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
-
8/7/2019 SRE Complete Chapters
30/114
-
8/7/2019 SRE Complete Chapters
31/114
Chapter # 03: Requirements Analysis
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
-
8/7/2019 SRE Complete Chapters
32/114
Chapter # 03: Requirements Analysis
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
-
8/7/2019 SRE Complete Chapters
33/114
Chapter # 03: Requirements Analysis
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
-
8/7/2019 SRE Complete Chapters
34/114
Chapter # 03: Requirements Analysis
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
-
8/7/2019 SRE Complete Chapters
35/114
Chapter # 03: Requirements Analysis
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
-
8/7/2019 SRE Complete Chapters
36/114
Chapter # 03: Requirements Analysis
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
-
8/7/2019 SRE Complete Chapters
37/114
Chapter # 03: Requirements Analysis
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 customers 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
-
8/7/2019 SRE Complete Chapters
38/114
Chapter # 03: Requirements Analysis
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
-
8/7/2019 SRE Complete Chapters
39/114
Chapter # 03: Requirements Analysis
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
-
8/7/2019 SRE Complete Chapters
40/114
Chapter # 03: Requirements Analysis
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 dont.
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
http://www.issco.unige.ch/projects/ewg96/node55.html#qltisohttp://www.issco.unige.ch/projects/ewg96/node55.html#qltiso -
8/7/2019 SRE Complete Chapters
41/114
Chapter # 03: Requirements Analysis
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 whichactions 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
-
8/7/2019 SRE Complete Chapters
42/114
Chapter # 03: Requirements Analysis
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
theusers 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
-
8/7/2019 SRE Complete Chapters
43/114
Chapter # 03: Requirements Analysis
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
-
8/7/2019 SRE Complete Chapters
44/114
Chapter # 03: Requirements Analysis
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
-
8/7/2019 SRE Complete Chapters
45/114
Chapter # 03: Requirements Analysis
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
-
8/7/2019 SRE Complete Chapters
46/114
Chapter # 03: Requirements Analysis
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 requ