06software Requirement Engineering(final)

Chapter 1 Software Requirement Engineering Introduction Done well, requirements engineering presents an opportunity to reduce costs and increase the quality of software systems. Done poorly, it could lead to a software project failure. So it’s no surprise that there has been much interest in software requirements engineering over the past 10 years or so. Many software project failures have been attributed to requirements engineering issues. These include poorly documented requirements, requirements that were impossible to satisfy, requirements that failed to meet the needs of users, and requirements creep--the gradual inclusion of unanticipated, undocumented, and poorly considered requirements. Even when projects do not fail outright, software developers now recognize that errors that occurs early in the development life cycle, particularly at the requirements stage, turn out to be the most difficult and costly to fix. This is especially true when the errors are not discovered until late in the life cycle--perhaps at implementation. The relatively recent attention to requirements engineering is fairly typical of the patterns seen in earlier advances in software engineering. Software engineers initially focused on programming methods, then on design methods, and are now focusing on requirements methods, in an attempt to introduce more discipline in the software engineering process. In the early days, requirements were developed in English text, but over time have evolved into structured and in some cases formal specifications. More recently there has been interest in requirements elicitation, because working with non-technical people can be among the most challenging areas of software development. In an effort to communicate with non-technical customers and understand their needs, software developers have teamed with experts from the social sciences to gain new perspectives on solving the thorny communication problems that can plague an acquisition effort. Systematic requirements analysis is also known as requirements engineering. It is sometimes referred to loosely by names such as requirements gathering, requirements capture, or

1

requirements specification. The term requirements analysis can also be applied specifically to the analysis proper, as opposed to elicitation or documentation of the requirements, for instance.

Requirements describe “WHAT” of a system not “HOW” Requirement engineering is a sub discipline of software engineering that is concerned with determining the goals, functions, and constrains of software systems. Ideally the requirement engineering process begins with a feasibility study activity, which leads to a feasibility report. If the feasibility study suggested that the product should be developed, then requirement analysis can begin. If requirement analysis precedes feasibility studies, which may foster outside the box thinking, then feasibility should be determined before requirements are finalized.

Crucial Process Steps The quality of a software product is only as good as the process that creates it. Without well written document:-- Developers do not know what to build -- Customers do not know what to expect -- What to validate nizations

2

Present State of Practice Most software development organizations agree to fact that there should be a set of activities called requirement engineering and their success is vital to the success of the entire project. There are some problems:1. Requirements are difficult to uncover 2. Requirements change 3. Over reliance on CASE Tools 4. Tight project Schedule 5. Communication barriers 6. Market driven software development 7. Lack of resources

3

Requirements Engineering

R

R

e

q

u

e

q

ir e

u

i r e

m

e R n e t sq

m

R

e

q

u

i r e

m

eR

n e t qs

R

e

q

u

i r e

m

e

n

t s

e

n

t s

E

n

g

i n

u E i r l ie c m i t a e t ni o t ns u S i r p e e m c e i f ni c t a s t M

a

n

a

g

Type of Requirements There are different types of requirements such as: 1) Known Requirements- Something a stakeholder believes to be implemented. 2) Unknown Requirements- Forgotten by the stakeholder because they are not needed

right now or needed only by another stakeholder. 3) Undreamt Requirements- Stakeholders may not be able to think of new requirements

due to limited domain knowledge.

Stakeholder: Anyone who should have some direct or indirect influence on the system requirements. ”Stakeholders” includes end-users who will interact with the system and everyone else in an organization who will be affected by it.

4

e

m

Functional and Non-Functional Requirements Software requirements are broadly classified as functional and non-functional requirements.

Functional Requirement: - Statements of services the system should provide how the system should react to particular inputs and how the system should behave in particular situations. They describe what the software has to do. They are also called product features. These are directly related to customer’s expectations and essential for the acceptance of product. It mainly describe:•

Describe functionality or system services

•

Depend on the type of software, expected users and the type of system where the software is used.

•

Functional user requirements may be high-level statements of what the system should do but functional system requirements should describe the system services in detail.

Non-Functional Requirement: -Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. These are mostly quality requirement that stipulate how well the software does what it has to do. Non-functional requirements for developers are maintainability, portability and testability. It mainly describe:•

Define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc.

•

Process requirements may also be specified mandating a particular system, programming language or development method.

•

Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless.

Non-functional classifications Product requirements – Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc.

Organizational requirements – Requirements which are a consequence of organizational policies and procedures e.g. process standards used, implementation requirements, etc.

5

External requirements – Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.

User and System Requirements User requirements are written for the users and include functional and non-functional requirements. Users may not be the experts of the software field; hence simple language should be used. User requirements should specify the external behavior of the system with some constraints and quality parameters. However, design issues should be avoided.

System requirements are derived from user requirements. They are expanded form of user requirements. They may be used as input to the designers for the preparation of software design document.

Interface Specification Interfaces issues are very important for the customers. A good software may not be appreciated if interfaces are not as per expectations of the customers. The types of interfaces are: 1.

Procedural interfaces: -These are called Application Programming Interfaces (APIs).

2.

Data Structures: -Used to transfer information from one module to another module.

3.

Representation of data: -The issues related to ordering of bits are established here.

Feasibility Studies A feasibility study looks at the viability of an idea with an emphasis on identifying potential problems and attempts to answer one main question: Will the idea work and should you proceed with it? Before you begin writing your business plan you need to identify how, where, and to whom you intend to sell a service or product. You also need to assess your competition and figure out how much money you need to start your business and keep it running until it is established. Feasibility studies address things like where and how the business will operate. They provide indepth details about the business to determine if and how it can succeed, and serve as a valuable tool for developing a winning business plan.

6

Why Are Feasibility Studies so Important? The information you gather and present in your feasibility study will help you: •

List in detail all the things you need to make the business work;

•

Identify logistical and other business-related problems and solutions;

•

Develop marketing strategies to convince a bank or investor that your business is worth considering as an investment; and

•

Serve as a solid foundation for developing your business plan.

Even if you have a great business idea you still have to find a cost-effective way to market and sell your products and services. This is especially important for store-front retail businesses where location could make or break your business. For example, most commercial space leases place restrictions on businesses that can have a dramatic impact on income. A lease may limit business hours/days, parking spaces, restrict the product or service you can offer, and in some cases, even limit the number of customers a business can receive each day.

The Components of a Feasibility Study •

Description of the Business: The product or services to be offered and how they will be delivered.

•

Market Feasibility: Includes a description of the industry, current market, anticipated future market potential, competition, sales projections, potential buyers, etc.

•

Technical Feasibility: Details how you will deliver a product or service (i.e., materials, labor, transportation, where your business will be located, technology needed, etc.).

•

Financial Feasibility: Projects how much start-up capital is needed, sources of capital, returns on investment, etc.

•

Organizational Feasibility: Defines the legal and corporate structure of the business (may also include professional background information about the founders and what skills they can contribute to the business).

Purpose of feasibility studies The purpose of a Feasibility Study is to identify the likelihood of one or more solutions meeting the stated business requirements. In other words, if you are unsure whether your solution will deliver the outcome you want, then a Project Feasibility Study will help gain 7

that clarity. During the Feasibility Study, a variety of 'assessment' methods are undertaken. The outcome of the Feasibility Study is a confirmed solution for implementation.

Focus of feasibility studies Steve McConnell has given the following points on which a feasibility study should focus and give proper emphasis to get good results: •

Is the concept viable?

•

Will it be possible to develop a product that matches the project’s vision statement?

•

What are the current estimated cost and schedule for the project?

•

How big is the gap between the original cost and schedule targets and current estimates?

•

Have the major risks to the project been identified and can they be surmounted?

•

Is the software development plan complete and adequate to support further development work?

The work done during the first 10-20 percent of the project should sufficiently answer these questions and give the top management enough information to decide whether to fund the rest of the project.

8

Chapter 2 Requirements Elicitation Requirement elicitation is perhaps most difficult, most critical, most error-prone, and most communication intensive aspect of software development. Elicitation can succeed only through an effective customer-developer partnership. Requirements elicitation comprises activities that enable the understanding of the goals, objectives, and motives for building a proposed software system. Elicitation also involves identifying the requirements that the resulting system must satisfy in order to achieve these goals. Selection of any method among number of methods of requirements elicitation. 1. It is the only method that we know. 2. It is our favorite method for all situations. 3. We understand intuitively that the method is effective in the present circumstances.

Normally we rely on first two reasons.

Interviews and Questionnaires •

Simple direct technique.

•

Interview may be open-ended or structured.

•

Context-free questions can help achieve bias-free interviews – See course web site for examples.

•

Then, it may be appropriate to search for undiscovered requirements by exploring solutions.

•

Convergence on some common needs will initiate a “requirements repository” for use during the project.

•

A questionnaire is no substitute for an interview.

Selection of stakeholder 9

1. 2. 3. 4.

Entry level personnel Middle level stakeholder Managers Users of the software (Most important)

Interview: Context free question •

Goal is to prevent prejudicing the user’s response to the questions.

•

Examples:

•

•

Who is the user?

•

Who is the customer?

•

Are their needs different?

•

Where else can a solution to this problem be found?

Context-free questions also parallel the questions salespeople are taught to ask as part of a technique called “solutions selling.” •

After context-free questions are asked, suggested solutions can be explored.

Interview: Show time: •

Establish Customer or User Profile

•

Assessing the Problem

•

Understanding the User Environment

•

Recap the Understanding

•

Analyst’s Inputs on Customer’s Problems

•

Assessing Your Solution (if applicable)

Brainstorming •

Brainstorming involves both idea generation and idea reduction.

•

The most creative, innovative ideas often result from combining, seemingly unrelated ideas.

•

Various voting techniques may be used to prioritize the ideas created.

•

Although live brainstorming is preferred, web-based brainstorming may be a viable alternative in some situations 10

Rules for Brainstorming •

Do not allow criticism or debate.

•

Let your imagination soar

•

Generate as many ideas as possible

•

Mutate and combine ideas

•

Idea Reduction – Pruning ideas that are not worthy of further discussion – Grouping of similar ideas into one super topic

•

Prioritize the remaining ideas

Facilitated Application specification Techniques (FAST) • • •

Similar to brainstorming sessions. Team oriented approach Creation of joint team of customers and developers.

Guidelines 1. 2. 3. 4. 5. 6. 7.

Arrange a meeting at a neutral site. Establish rules for participation. Informal agenda to encourage free flow of ideas. Appoint a facilitator. Prepare definition mechanism board, worksheets, wall stickier. Participants should not criticize or debate.

Quality Function Deployment •

Incorporate voice of the customer. Prime concern is customer satisfaction. The QFD method has the following steps: 1. Identify stakeholders 2. List out requirements 3. Degree of importance to each requirement.

The Use Case Approach Use Cases are structured outline or template for the description of user requirements modeled in a structured language like English. Use case Scenarios are unstructured descriptions of user requirements. Use case diagrams are graphical representations that may be decomposed into further levels of abstraction.

11

A use case is a technique for documenting the potential requirements of a new system or software change. Each use case provides one or more scenarios that convey how the system should interact with the end user or another system to achieve a specific business goal. Use cases are often co-authored by requirements engineers and stakeholders. Use cases are deceptively simple tools for describing the behavior of software or systems. A use case contains a textual description of all of the ways which the intended users could work with the software or system. Use cases do not describe any internal workings of the system, nor do they explain how that system will be implemented. They simply show the steps that a user follows to perform a task. All the ways that users interact with a system can be described in this manner.

Jacobson & others proposed a template for writing Use cases as shown below:

Flow of Events 12

Chapter 3 Requirements Analysis Requirements analysis in systems engineering and software engineering, encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders, such as beneficiaries or users. Requirements analysis is critical to the success of a development project. Requirements must be actionable, measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design. Requirements analysis, also called requirements engineering, is the process of determining user expectations for a new or modified product. These features, called requirements, must be quantifiable, relevant and detailed. In software engineering, such requirements are often called 13

functional specifications. Requirements analysis is an important aspect of project management.

Requirements analysis is the first stage in the systems engineering process and software development process.

Requirement analysis is concerned with the process of analyzing requirements to * Detect and resolve conflicts between requirements * Discover the bounds of the software and how it must interact with its environment * Elaborate system requirements to derive software requirements The traditional view of requirements analysis has been that it be reduced to conceptual modeling using one of a number of analysis methods such as the Structured Analysis and Design Technique (SADT). While conceptual modeling is important, we include the classification of requirements to help inform trade-offs between requirements (requirements classification) and the process of establishing these trade-offs (requirements negotiation). Care must be taken to describe requirements precisely enough to enable the requirements to be validated, their implementation to be verified, and their costs to be estimated.

Requirement analysis is hard Major causes of project failures •Poor user input •Incomplete requirements •Changing requirements Difficulties • Complex problems, unknown domains, nontechnical customers, communicationintensive Essential tools • Classification of requirements 14

•

Use cases

Requirement analysis tasks 1. Problem Recognition: as perceived by the customer. 2. Evaluation & Synthesis: The analysts define data objects, evaluate the flow of

information, define all software functions, understand system behavior, establish system interface characteristics and design constraints. 3. Modeling: models of data, information and control flow, and operational behaviors. 4. Specification: a model of the software is created and evaluated by both software engineers and customers. 5. Review: of software requirements specifications done by developer and customer.

Analysis Principals 1. Information domain of a problem must be represented and understood 2. Required functions must be defined 3. Behavior of software must be represented 4. Models that depict information, function, and behavior must be partitioned in a layered or hierarchical fashion 5. Analysis process should move from essential info to implementation detail.

Requirement analysis steps 1.

Draw the context diagram: -The context diagram is a model that defines the

boundaries and interfaces of the proposed system with the external world. It identifies the entities outside the proposed system that interact with the system. 2. Development of a prototype(optional): -One effective way to find out what the customer really wants is to construct a prototype, something that looks and preferably acts like a part of the system they say they want. Some projects are developed for general market. The prototype should be built quickly and a relatively low cost. hence it will always have limitations and would not be acceptable in the final system. 3. Model the requirements: -The process usually consists of various graphical representations of the functions, data entities, external entities and the relationship between them. The graphical view may help to find incorrect, inconsistent, missing and superfluous requirements. Such models include data flow diagrams, Entity relationship diagrams, data dictionaries, state- transition diagrams etc. 4. Finalize the requirements: -After modeling the requirements, we will have better understanding of the system behavior. The inconsistencies and ambiguities have been identified and corrected. Flow of data amongst various modules has been analyzed. Now we finalized requirements and next step is to document these requirements in a prescribed format.

15

Analysis model elements 1 2 3 4

Data Dictionary  Contains descriptions of all data objects used Entity-Relationship Diagram (ERD)  Describes relationships between data objects Data Flow Diagram (DFD)  Describes data flow & transformation State Transition Diagram (STD)  Describes system behavior

Data flow diagrams A data-flow diagram (DFD) is a graphical representation of the "flow" of data through an information system. DFDs can also be used for the visualization of data processing (structured design). On a DFD, data items flow from an external data source or an internal data store to an internal data store or an external data sink, via an internal process.

16

A DFD provides no information about the timing or ordering of processes, or about whether processes will operate in sequence or in parallel. It is therefore quite different from a flowchart, which shows the flow of control through an algorithm, allowing a reader to determine what operations will be performed, in what order, and under what circumstances, but not what kinds of data will be input to and output from the system, nor where the data will come from and go to, nor where the data will be stored (all of which are shown on a DFD).

There are only five symbols that are used in the drawing of business process diagrams (dataflow diagrams). These are now explained, together with the rules that apply to them.

This diagram represents a banking process, which maintains customer accounts. In this example, customers can withdraw or deposit cash, request information about their account or update their account details. The five different symbols used in this example represent the full set of symbols required to draw any business process diagram.

External Entity:-

An external entity is a source or destination of a data flow which is outside the area of study. Only those entities which originate or receive data are represented on a business process diagram. The symbol used is an oval containing a meaningful and unique identifier.

17

Process

A process shows a transformation or manipulation of data flows within the system. The symbol used is a rectangular box which contains 3 descriptive elements: Firstly an identification number appears in the upper left hand corner. This is allocated arbitrarily at the top level and serves as a unique reference. Secondly, a location appears to the right of the identifier and describes where in the system the process takes place. This may, for example, be a department or a piece of hardware. Finally, a descriptive title is placed in the centre of the box. This should be a simple imperative sentence with a specific verb, for example 'maintain customer records' or 'find driver'.

Data Flow

A data flow shows the flow of information from its source to its destination. A data flow is represented by a line, with arrowheads showing the direction of flow. Information always flows to or from a process and may be written, verbal or electronic. Each data flow may be referenced by the processes or data stores at its head and tail, or by a description of its contents.

Data Store

18

A data store is a holding place for information within the system: It is represented by an open ended narrow rectangle. Data stores may be long-term files such as sales ledgers, or may be short-term accumulations: for example batches of documents that are waiting to be processed. Each data store should be given a reference followed by an arbitrary number.

Resource Flow

A resource flow shows the flow of any physical material from its source to its destination. For this reason they are sometimes referred to as physical flows. The physical material in question should be given a meaningful name. Resource flows are usually restricted to early, high-level diagrams and are used when a description of the physical flow of materials is considered to be important to help the analysis.

Data dictionaries Data dictionaries are simply repositories to store information about all data items defined in DFDs. As the requirements stage, the data dictionary should at least define customer data items, to ensure that the customer and developer use the same definitions and terminologies. Typical information stored includes: • • • • • •

Name of the data item Aliases (other names for item) Descriptions/purposes Related data items Range of values Data structure definition/form

The name of the data item is self explanatory. Aliases include other names by which this data item is called e.g., DEO for data entry operator and DR for Deputy Registrar. Description/purpose is a textual description of what the data item is used for or why it exists. Related data item capture relationship between data items capture relationships between data items. The data dictionary can be used to: • Create on ordered listing of all data items. •

Create an ordered listing of a subset of data items. 19

•

Find a data item name from a description.

•

Design the software and test cases.

Entity relationship diagrams In software engineering, an Entity-Relationship Model (ERM) is an abstract and conceptual representation of data. Entity-relationship modeling is a database modeling method, used to produce a type of conceptual schema or semantic data model of a system, often a relational database, and its requirements in a top-down fashion. Diagrams created using this process are called entity-relationship diagrams, or ER diagrams or ERDs for short. There are three basic elements in ER models: Entities are the "things" about which we seek information. Attributes are the data we collect about the entities. Relationships provide the structure needed to draw information from multiple entities.

Entities An entity is a fundamental thing of an organization about which data may be maintained. An entity has its own identity, which distinguishes it from each other entity. An entity type is the description of all entities to which a common definition and common definition and common relationship and attributes apply. An entity is a real-world item or concept that exists on its own. In our example, a particular student (such as, "Emanuel Vagas"), team, lab section, or experiment is an entity. The set of all possible values for an entity, such as all possible students, is the entity type. In an ER model, we diagram an entity type as a rectangle containing the type name, such as student

Definition

An entity is a real-world item or concept that exists on its own. The set of all possible values for an entity is the entity type.

ER diagram notation for entity student

20

Attributes Each entity has attributes, or particular properties that describe the entity. For example, student Emanuel Vagas has properties of his own Student Identification number, name, and grade. A particular value of an attribute, such as 93 for the grade, is a value of the attribute. Most of the data in a database consists of values of attributes. The set of all possible values of an attribute, such as integers from 0 to 100 for a grade, is the attribute domain. In an ER model, an attribute name appears in an oval that has a line to the corresponding entity box, such as in Figure 3. Definition

An attribute of an entity is a particular property that describes the entity. The set of all possible values of an attribute is the attribute domain.

Figure 3. ER diagram notation for an attribute domain (StudentGrade) of an entity type (student)

Relationship A relationship type is a set of associations among entity types. For example, the student entity type is related to the team entity type because each student is a member of a team. In this case, a relationship or relationship instance is an ordered pair of a specific student and the student's particular physics team, such as (Emanuel Vagas, Phys201F2005A04), where Phys201F2005A04 is Emanuel's team number. Figure 8 illustrates three relationships. Unfortunately, Itnatios Trekas had to drop the course and retake it another semester. Consequently, his name is associated with two team numbers.

21

We use a diamond to illustrate the relationship type in an ER diagram, such as in Figure 9. We arrange the diagram so that the relationship reads from left to right, "a student is a member of a team." Alternatively, we can arrange the components from top to bottom. Definition

A relationship type is a set of associations among entity types. A relationship or relationship instance is an ordered pair consisting of particular related entities.

Figure 9. ER diagram notation for relationship type, MemberOf

ER diagram looks like

22

Developing an ERD Developing an ERD requires an understanding of the system and its components. Consider a hospital: Patients are treated in a single ward by the doctors assigned to them. Usually each patient will be assigned a single doctor, but in rare cases they will have two. Healthcare assistants also attend to the patients; a number of these are associated with each ward. Initially the system will be concerned solely with drug treatment. Each patient is required to take a variety of drugs a certain number of times per day and for varying lengths of time. The system must record details concerning patient treatment and staff payment. Some staff is paid part time and doctors and care assistants work varying amounts of overtime at varying rates (subject to grade). The system will also need to track what treatments are required for which patients and when and it should be capable of calculating the cost of treatment per week for each patient (though it is currently unclear to what use this information will be put).

How do we start an ERD? 1. Define Entities: these are usually nouns used in descriptions of the system, in the discussion of business rules, or in documentation; identified in the narrative (see highlighted items above). 2. Define Relationships: these are usually verbs used in descriptions of the system or in discussion of the business rules (entity ______ entity); identified in the narrative. 3. Add attributes to the relations: these are determined by the queries, and may also suggest new entities, e.g. grade; or they may suggest the need for keys or identifiers. What questions can we ask? Which doctors work in which wards? How much will be spent in a ward in a given week? How much will a patient cost to treat? How much does a doctor cost per week? Which assistants can a patient expect to see? Which drugs are being used?

23

4. Add cardinality to the relations Many-to-Many must be resolved to two one-to-many with an additional entity Usually automatically happens Sometimes involves introduction of a link entity (which will be all foreign key) Examples: Patient-Drug 5. This flexibility allows us to consider a variety of questions such as: a. Which beds are free? b. Which assistants work for Dr. X? c. What is the least expensive prescription? d. How many doctors are there in the hospital? e. Which patients are family related?

Reading an ERD It takes some practice reading an ERD, but they can be used with clients to discuss business rules. These allow us to represent the information from above such as the E-R Diagram below:

24

There are three types of relationships between entities:

One-to-One: one instance of an entity (A) is associated with one other instance of another entity (B). For example, in a database of employees, each employee name (A) is associated with only one social security number (B). One-to-one relationships



One-to-Many: one instance of an entity (A) is associated with zero, one or many instances of another entity (B), but for one instance of entity B there is only one instance of entity A. For example, for a company with all employees working in one building, the building name (A) is associated with many different employees (B), but those employees all share the same singular association with entity A.



Many-to-many: one instance of an entity (A) is associated with one, zero or many instances of another entity (B), and one instance of entity B is associated with one, zero or many instances of entity A. For example, for a company in which all of its employees work on multiple projects, each instance of an employee (A) is associated with many instances of a project (B), and at the same time, each instance of a project (B) has multiple employees (A) associated with it.

Software Prototyping A prototype is a working model of one or more aspects of the project system. It is constructed and tested quickly and inexpensively in order to test out assumptions. Two most popular prototyping approaches: Throw-away prototypes: -Here the prototype is used only to test out some ideas and is then discarded when the true development of the operational system is commenced. The prototype could be developed using a different software environment or even on a different kind of hardware platform.

25

Evolutionary prototypes: -The prototype is developed and modified until it is finally in a state where it can become the operational system. In this case the standards that are used to develop the software have to be carefully considered.

Requirements Documentation •

Requirements documentation is very important activity after the requirements elicitation and analysis. This is the way to represent requirements in a consistent format. Requirements documentation is called Software Requirements Specification (SRS).

•

The requirements document is the official statement of what is required of the system developers.

•

Should include both a definition and a specification of requirements.

•

It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it should do it.

•

The SRS is a specification for a particular software product, program or set of programs that performs certain functions in a specific environment. It serves a number of purposes depending on who is writing it. •

First, the SRS could be written by the customer of a system. It is used to define the needs and expectations of the customers.

•

Second, the SRS could be written by a developer of the system. In this SRS is written for different purpose and serve as a contract document between customer and developer.

Nature of the SRS The basic issues that SRS writer(s) shall address are the following: 1.

Functionality: What the software is supposed to do?

2.

External interfaces: How does the software interact with people, the system’s hardware, other hardware, and other software?

3.

Performance: What is the speed, availability, response time, recovery time, etc. of various software functions?

4.

Attributes: What are the considerations for portability, correctness, maintainability, security, reliability, etc.?

5.

Design constraints imposed on an implementation: Are there any required standards in effect, implementation language, policies for database integrity, resource limits, operating environment(s), etc.?

26

Since the SRS has a specific role to play in the software development process, SRS writer(s) should be careful not to go beyond the bounds of that role. This means the SRS 1. Should correctly define all the software requirements. A software requirement may exist

because of the nature of the task to be solved or because of a special characteristic of the project. 2. Should not describe any design or implementation details. These should be described in

the design stage of the project. 3. Should not impose additional constraints on the software. These are properly specified in

other documents such as a software quality assurance plan.

Characteristics of a good SRS The skill of writing a good SRS document usually comes from the experience gained from writing similar documents for many problems. However, the analyst should be aware of the desirable qualities that every good SRS document should possess. Some of the identified desirable qualities of the SRS documents are the following: 1.

Concise: -The SRS document should be concise and at the same time unambiguous, consistent, and complete. Verbose and irrelevant descriptions reduce readability and also increase error possibilities.

Unambiguous: -An SRS is unambiguous if and only if, every requirement stated therein has only one interpretation.

Consistent: -An SRS is consistent if and only if, no subset of individual requirements described in it conflict.

Complete: -An SRS is complete if and only if, it includes the following elements:a. All significant requirements, whether related to functionality, performance, design

constraints, attributes or external interfaces. b. Responses to both valid & invalid inputs. c. Full Label and references to all figures, tables and diagrams in the SRS and

definition of all terms and units of measure. 2.

Structured: -The SRS document should be well-structured. A well-structured document is easy to understand and modify. In practices, the SRS document undergoes several revisions to cope with the customer requirements. Often, the customer requirements evolve over a period of time. Therefore, in order to make the modifications to the SRS document easy, it is important to make the document well-structured.

3.

Black-box view: -It should only specify what the system should do and refrain from stating how to do. This means that the SRS document should specify the external behavior of the system and not discuss the implementation issues. It should view the system to be developed as a black box, and should specify the externally visible behavior of the system. For this reason, the SRS document is also called the black-box specification of a system. 27

4.

Conceptual integrity: -The SRS document should exhibit conceptual integrity so that the reader can easily understand the contents.

5.

Response to undesired events: -The document should characterize acceptable responses to undesired events. These are called system responses to exceptional conditions.

6.

Verifiable: -All requirements of the system as documented in the SRS document should be verifiable. This means that it should be possible to determine whether or not requirements have been met in an implementation. Requirements such as ‘the system should be user friendly’ are not verifiable.

7.

Traceable: - It means that it would be possible to tell which design components corresponds to which requirement, which code corresponds to which design component, and which test case corresponds to which requirements, etc. Two types of traceability are recommended. a.

Backward Traceability: -This depends upon each requirement explicitly referencing its source in earlier documents. It is especially important when the software product enters the operation and maintenance phase.

b.

Forward Traceability: -This depends upon each requirement in the SRS having a unique name or reference number.

Organization of the SRS The Institute of Electricals and Electronics Engineers (IEEE) has published guidelines and standards to organize an SRS documentIEEE87, IEEE94]. Different projects may require their requirements to be organized differently, that is no one method that is suitable for all projects. The general organization of an SRS is as follows [IEEE93]. 1. Introduction 1) Purpose: -Identify the purpose of this SRS and its intended audience. 2) Scope: -

a. Identify the software product(s) to be produced by name. b. Explain what the software product(s) will, and if necessary, will not do. c. Describe the application of the software being specified, including relevant benefits, objectives, and goals. d. Be consistent with similar statements in higher-level specifications if they exist. 3) Definitions, Acronyms, and Abbreviations: -Provide the definitions of all terms,

acronyms, and abbreviations required to properly interpret the SRS. 4) References: -

a. Provide a complete list of all documents referenced elsewhere in the SRS. 28

b. Identify each document by title, report number (if applicable), date and publishing organization. c. Specify the sources from which the references can be obtained. 5) Overview: -

a. Describe what the rest of the SRS contains. b. Explain how the SRS is organized. 2. The Overall Description: -Describe the general factors that affect the product and its requirements. It provides a background for those requirements, which are defined and make them easier to understand. 1) Product Perspective: -Put the product into perspective with other related products. If the

product is independent and totally self-contained, it should be so stated here. If the SRS defines a product that is a component of a larger system, as frequently occurs, then this relates to the requirements of the larger system to functionality of the software and identifies interfaces between that system and software. 2) Product Functions: -Provide a summary of the major functions that the software will

perform. Sometimes the function summary that is necessary for this part can be taken from the section of higher-level specification (if one exists) that allocates particular functions to the software product. 3) User Characteristics: -Describe those general characteristics of the intended users of the

product including educational level, experience, and technical expertise. Do not state specific requirements. 4) Constraints: -Provide a general characteristic of any other items that will limit the

developer’s options. These can include regulatory policies, interface to other applications, parallel operation, audit functions, control functions, reliability requirements, etc. 5) Assumptions and Dependencies: -List of factors that affect the requirements stated in

the SRS. These factors are not design constraints on the software but are, rather any changes to them that can affect the requirements in the SRS. 6) Apportioning of Requirements: -Identify requirements that may be delayed until future

versions of the system. 3. Specific Requirements 1) External Interfaces: -This contains a detailed description of all inputs into and outputs

from the software system. It complements the interface description. 2) Functions: -Functional requirement define the fundamental actions that must take place

in the software in accepting and processing the inputs and in processing and generating the output.

29

3) Performance Requirements: -This specifies both static and dynamic numerical

requirements placed on the software or on human interaction with the software, as a whole. 4) Logical Database Requirements: -This specifies the logical requirements for any

information that is to be placed into a database. 5) Design Constraints: -Specify design constraints that can be imposed by other standards,

hardware limitations, etc. 6) Software System Attributes: -There are number of quality attributes of software that can

serve as requirements. Some of them are reliability, security, availability, maintainability and portability. 7) Organizing the Specific Requirements: -For anything but trivial systems the detailed

requirements tend to be extensive. Some of these organizations are described as user class, objects, features, stimulus, response and functional hierarchy. 4. Change Management Process: -Identify the change management process to be used to identify, log, evaluate, and update the SRS to reflect changes in project scope and requirements. 5. Document Approval: -Identify the approvers of the SRS document. Approver’s name, signature, and date should be used. 6. Supporting Information: -It makes SRS easier to use. It includes: •

Table of Contents

•

Index

•

Appendices

Requirements Validation Check that our requirements definitions accurately reflect all of the stakeholders’ needs (i.e., we build the system right). The objective of requirements validation is to certify that the SRS document is an acceptable document of the system to be implemented. This helps us to find errors in the document and improves the quality of the software development process. Sometimes we confuse between analysis and validation. However, analysis works with raw requirements as elicited from the various stakeholders whereas validation works with a final draft of the SRS document with negotiated and agreed requirements. There are many requirement validation techniques 30

SRS document: -It should be a final draft, not an unfinished draft and should be formatted/organized as per IEEE standards.

Organizational standards: -Every organization should have some quality standards for SRS document and other activities. These standards will be used for reviewing during validation.

Organizational knowledge: -Knowledge, often implicit, of the organization which may be used to judge the realism of the requirements.

Problem list: -List of discovered problems in the requirements document. Approved actions: -List of approved actions in response to the requirements problems.

Requirements reviews This is a popular requirements validation technique where a group of people will read the SRS document and look for possible problems. These identified problems may be discussed in the group and some actions may also be approved in order to get rid of these problems. The requirements review processes are:1.

Plan review: -The review team is selected and time and place for review meeting is fixed.

2.

Distribute SRS document: -The SRS document is distributed to all the members.

3.

Read SRS document: -Each member should read the document carefully to find conflicts, omissions, inconsistencies, deviations from standards and other problems.

4.

Organize review meeting: -Each member presents his/her views and identified problems. The problems are discussed and set of actions to address the problem is approved.

5.

Follow-up actions: - The chairperson of the team checks the approved actions have been carried out.

6.

Revise SRS document:-The SRS document is revised to reflect the approved actions. At this stage, it may be accepted or may be reviewed.

Desirable Characteristics in Review Checklist Are the Requirements correct? •

Ensure common understanding with the customer/stakeholders of the requirements definitions.

Are the requirements consistent? •

Ensure there are no conflicting requirements. 31

Are the requirements unambiguous? •

Multiple readers (reviewers) of the document should not walk away with different but valid interpretations of the document

Are the requirements complete? •

The requirements is considered to be specifies required behavior and output for all possible inputs in all possible states.

Are the requirements feasible? •

Does a solution to the customer needs exist?

Is every requirement relevant? •

Check if the requirements include functions that are unrelated to the customers’ needs.

Are the requirements testable? Are the requirements traceable? •

Requirements are organized and uniquely labeled (enumerated) for reference. Every entry in the requirements definition has a corresponding entry in the requirements specification, and vice versa.

Requirement Management Requirement management is a new term which has been rapidly adopted by industry. It is a process of understanding and controlling changes to system requirements. Most of the times, requirements are not independent; but are dependent on each other. Hence, one change may have implications on other requirements and thus make the task much more difficult and challenging.

Enduring and Volatile Requirements i.

Enduring Requirements: -These are core requirements and are related to main activity of the organization. For a library management system, issue/return a book, cataloging etc. are core activities and are stable for any system. Hence, enduring requirements are stable and are not changed easily.

ii.

Volatile requirements: -These requirements are likely to change during software development life cycle or even after delivery of the product. There are many reasons for such changes some of the reasons are: •

Changes to the environment

•

Changes in technology

•

Changes in policies 32

•

Changes in customer’s expectations

Requirements Management Planning Requirement management planning is very critical, but important for the success of any project. The process of requirement management ends when the final product is released, and the customer is fully satisfied. However, the fewer modifications, may also be better for everybody. Tracing requirements also involves additional tests, performed from time to time, to ensure that the process runs smoothly and errors are identified and correctly early on. When faced with a big project, we may have different sets of requirements, some that apply to the entire project, and some for parts of it. When a certain design is implemented for certain requirements, make a note about the effects and the alternatives it may be useful for future project or even for the same project, if the customer is not satisfied with the result.

Requirements Change Management The customers expect modern software to be evolved and sufficiently flexible to accommodate changing user’s needs. This expectation, however, is untempered by the fact that changing requirements are recognized as a major cause of project failure. This may also have a degrading effect on the underlying design of a system. The fact of life is that software requirements change and evolve from inception of deployment. Hence changes to requirements are carefully traced, analyzed and their effects on the overall system are properly assessed. The requirements change process should include the following activities to be carried out when a change is needed in the requirements • Allocating adequate resources (Assignment of Responsibilities).

I.

•

Analysis of requirement changes (Management of Changes).

•

Documenting requirements (Documentation).

•

Creating requirements traces throughout the project life cycle from inception to the final work products (Requirements traceability).

•

Establishing team communication (communication of change).

•

Establishing a baseline for requirements specification (establishment of baseline).

Assignment of responsibilities: - All changes should be approved or rejected by the competent authority for the project. It may be project manager, project lead or may other equivalent person. After the decision, work is further given to individuals to carried out desired modifications.

II.

Management of Changes: - It is an important activity for the implementations of any change. Whenever a request is received for any addition/modification a change 33

request is created through a specified request form. The request is analyzed due to its impact or overall project cost, resources allocated and delivery schedule of the project. After the implementation of any change, a formal notice is issued to all stakeholders. III.

Documentation: - It is required to keep track of every activity of the project. Success of any software project lies in the documentation. It is very pertinent to note that without documentation, project future is in dark and with every passing day, it leads towards disaster.

IV.

Requirement Traceability: - It is a technique to provide relationships between requirements, design and implementation in order to manage the effect of change and its impact on the success of the project. Every requirement should be traceable any and every piece of design work may be traced to one or more requirements in the project.

V.

Communication of Change: -The most problematic changes to the requirement specification have been the ones that are not communicated to every stakeholder. Communication failures typically occur when we may drop a feature or change a performance requirement without communication to others.

VI.

Establishment of Baseline: -After the approval of a change, it is communicated to all. If every stakeholder agrees to the change, it is implemented and tested. Baseline is the tested version of a set of requirements representing a conceptual milestone, serves as the basis for further development. The steps for baseline establishment are: •

Approval of change from competent authority.

•

Communicate the approval to all stakeholders.

•

History of change is maintained.

34

Chapter 4 Tools of requirement engineering Accept 360° from Accept Software Corporation It is a requirements management tool that also supports product planning. Tools help users to define and track feature dependencies with tree diagrams, and to relate these to the market, project plans, implementation considerations and competitor analyses.

Accompa from Accompa It is a requirements management service provided on the Web for a small monthly fee per user. It can be customised with any number of fields and reports using sorts and filters. It has Web 2 style collaboration mechanisms for discussing and agreeing requirements. A Wizard guides the creation of specifications, which can be exported to Word, HTML, Excel, PDF. Raj Patel of Accompa, Inc. writes: "Accompa is an affordable, web-based requirement tool that enables product managers and project managers to capture, track and manage requirements. It can be customized right from the web-interface to fit an organization's needs. It features extensive collaboration features such as integrated discussion boards and social tags. A 30-day free trial is available." 35

Active Focus from Falafel Software (formerly Xapware) It is said to support the software application life-cycle.

Agility from Agile Edge It is a tracking database for user requirements, issues, tasks and bug tracking, permitting tracing between these items. There is a simple user interface displaying a table of items with status, symbols and text.

Agilo for Scrum from Agile 42 It is a tool for Scrum implementation, agile development, requirements and user stories. Marion Eickmann of Agile42 writes: "Even if Agilo is not a pure requirements tool, we strongly connect the Scrum ideas with requirements engineering."

Aligned Elements from Aligned AG It is a tool for handling requirements traceability and risk in the medical device industry. It includes a Requirements Management module. Its purpose is to handle all the evidence needed in the strict regulatory environment of medical devices. This seems to represent a trend (cf Comply Pro) towards specialised products performing essentially familiar RM tasks but using the language of a particular domain. Karl Johan Larsson of Aligned writes: "Aligned Elements is a requirement management solution targeted towards the Medical Device industry and is essentially built to manage Design History Files. Aligned Elements incorporate all relevant parts of the DHF Management process such as specifications, test cases, FMEA risk analysis, structured reviews, trace analysis, validation checks and is controlled by FDA QSR 21 CFR Part 11 user management etc."

Arcway Cockpit from Arcway AG It is a visual RE tool in which written requirements provide the bridge between different "visual landscapes" such as the business landscape and the IT landscape. The "landscapes" are defined visually with block diagrams or "maps" showing interfaces between people, processes, and software. The diagramming notation and visual concept seems to be unique to Arcway, while the idea of tracing between business processes and IT systems is classical but very freshly expressed. The examples seem to be strongly oriented to transactions and databases: whether the concept would work for other kinds of systems is unclear, though the principle of connecting events in the world to events and structures in the machine is quite general. This looks like the most exciting new product of 2007. Peter Aschenbrenner of Arcway AG writes: "ARCWAY Cockpit is a tool for managing requirements. It supports ARCWAY’s concept 36

of visual requirements engineering (VRE). In VRE requirements are linked to visual high-level models of the system under design. Requirements specified in ARCWAY Cockpit can be imported from and exported to MS Excel. A fully customizable MS Word, HTML and Docbook report interfaces allows for ad-hoc reports of specific requirements or complete specification documents."

ARM (Automated Requirement Measurement) from NASA It is a simple tool that carries out a set of checks on a list of (shall-statement) requirements in plain text. As such it can be applied to almost any set of contractual style requirements just by exporting them to a plain text file and then running ARM. It helps to find a range of possible problems. Once you get the idea, it is easy to re-implement a set of ARM-like rules with your own extras in a scripting language.

Banana Scrum from CodeSprinters It is a web-based project support tool for agile software development, using the Scrum method, and suitable for use with programming languages such as Python and Ruby on Rails. Requirements are captured on the equivalent of index cards and immediately coded in short iterations known as Sprints.

Blueprint from Blueprint Inc. This tool (formerly Profesy) won the 2005 Gartner Cool Vendor prize for being “innovative, impactful, and intriguing”. It was sold as a 'Visual Requirements Definition and Validation product' and is said to integrate intelligently with a range of 3rd-party tools. It assists with the creation of requirements, flowcharts, test scenarios and documentation. Tony Higgins of Sofea writes: Profesy provides a unified approach to Requirements Definition and Test Development. 1) For Requirements Definition, it provides business analysts with a powerful workbench to model, simulate, and validate business processes, business requirements and system requirements together to create a collaborative and highly visual elicitation, definition and approval process. 2) For Test Development, Sofea provides test planners with a powerful test development workbench to analyze requirements and automatically generate test scenarios. Test planners can incorporate scope and policy driven test strategies into the requirements model (to drive multi-level, risk, impact, regression testing). 3) After establishing a baseline, Sofea’s powerful integration capability is used to extract formal artifacts such as requirements and tests into leading Requirements Management, Design and Test Execution platforms. The resulting impact is that test

37

planning is completed early in the development project and all tests are 100% traceable to high-quality validated requirements.

Caliber-RM from Borland It is a well-known requirements management tool. It is intended for large and complex systems, and provides a database of requirements with traceability. The company views requirements as part of the software quality management process, which it considers also includes testing and defect tracking. Caliber is Internet-based, and it handles document references, user responsibility, traceability, status and priority. Chip Carey of Starbase (former owners of Caliber) wrote: "The exciting thing about RM and Caliber RM in particular is that it brings all departments together within the software development lifecycle and puts them all on the same page - it provides a mechanism for communication and collaboration and effectively provides a synergy where before they were perhaps separate efforts and maybe counter-productive."

CASE SPEC (formerly AnalystPro) from Goda Software It supports requirements editing and traceability, change control, diagrams including use cases, and other features of full RM tools at a low price per seat. CASE Spec is described as a "Specification, Requirements & Lifecycle Solution". Kris of Goda Software, Inc writes: Analyst Pro is an affordable, scalable and collaborative tool for requirements tracking, traceability analysis and document management. It is easily deployable and customizable to your project needs."

38

Conclusion Fritz Bauer defined software engineering as “The establishment and use of sound engineering principles in order to obtain economically developed software that is reliable and works efficiently on real machines.” Stephen Schach defined the same as “A discipline whose aim is the production of quality software, software that is delivered on time, within budget, and that satisfies its requirements.” Requirements analysis in systems engineering and software engineering, encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders, such as beneficiaries or users. Requirements analysis is critical to the success of a development project. Requirements must be actionable, measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design. Thus we can conclude that, “Requirements engineering is the branch of

software engineering concerned with the real world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behavior, and to their evolution over time and across software families.”

39