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


2/114


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


3/114


4/114


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


5/114


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


6/114


7/114


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/114


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


9/114


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


10/114


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


11/114


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


12/114


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


13/114


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


14/114


(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


15/114


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


16/114


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


17/114


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


18/114


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


19/114


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


20/114


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


21/114


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


22/114


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


23/114


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


24/114


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


25/114


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


26/114


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


27/114


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


28/114


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


29/114


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


30/114


31/114


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


32/114


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


33/114


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


34/114


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


35/114


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


36/114


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


37/114


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


38/114


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


39/114


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


40/114


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


41/114


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


42/114


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


43/114


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


44/114


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


45/114


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


46/114


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

Documents

SRE Complete Chapters