بسم اهلل الرحمن الرحيمSudan University of science and Technology

College of graduate studies

College of Computer Science and Information Technology

Msc in Computer Science – Software Engineering Track

Requirements Engineering

Prepared by:

1. Mohamed zeinelabdeen.

2. Omer Salih dawood.

Introduction:

Requirements Engineering (RE) is a set of activities concerned with identifying and communicating the

purpose of a software-intensive system, and the contexts in which it will be used. Hence, RE acts as the

bridge between the real-world needs of users, customers, and other constituencies affected by a software

system, and the capabilities and opportunities afforded by software-intensive technologies.The name

“requirements engineering” may seem a little awkward. Both words carry some unfortunate connotations:

„Requirements‟ suggests that there is someone out there doing the „requiring‟ – a specific customer

who knows what she wants.

„Engineering‟ suggests that RE is an engineering discipline in its own right, whereas it is really a

fragment of a larger process of engineering software-intensive systems [1].

Software Requirements serve two major roles in a developmental effort.

They describe what to develop and

Describe when the development is completed.

Levels and types of requirements:

Most software practitioners just talk about “the requirements.” However, by recognizing that there are

different levels and types of requirements, as illustrated in Figure practitioners gain a better understanding

of what information they need to elicit, analyze, specify, and validate when they define their software

requirements.

Business requirements define the business problems to be solved or the business opportunities to be

addressed by the software product. In general, the business requirements define why the software product

is being developed.

User requirements look at the functionality of the software product from the user‟s perspective. They

define what the software has to do in order for the users to accomplish their objectives. The product‟s

functional requirements that define the software functionality must be built into the product to enable

users to accomplish their tasks, thereby satisfying the business Requirements. As opposed to the business

requirements, business rules are the specific policies, standards, practices, regulations, and guidelines that

define how the users do business (and are therefore considered user-level requirements). The software

product must adhere to these rules in order to function appropriately within the user‟s domain. User-level

quality attributes are nonfunctional characteristics that define the software product‟s quality. Sometimes

called the “ilities,” quality attributes include reliability, availability, security, safety, maintainability,

portability, usability, and other properties. A Quality attribute may translate into product-level functional

requirements for the software

That specify what functionality must exist to meet the nonfunctional attribute. For example, an ease of

learning requirement might translate into the functional requirement of having the system display pop-up

help when the user hovers the cursor over an icon.

A quality attribute may also translate into product-level nonfunctional requirements that specify the

characteristics the software must possess in order to meet that attribute. For example, an ease-of-use

requirement might translate into nonfunctional requirements for response time to user commands or report

requests. The external interface requirements define the requirements for the information flow across

shared interfaces to hardware, users, and other software applications outside the boundaries of the

software product being developed. The constraints define any restrictions imposed on the choices that the

supplier can make when designing and developing the software. For example, there may be a requirement

that the completed software use no more than 50 percent of available system memory or disk space in

order to ensure the ability for future enhancement.

The data requirements define the specific data items or data structures that must be included as part of

the software product. For example, a payroll system would have requirements for current and year-to-date

payroll data.

The software may be part of a much larger system that includes other components. In this case, the

business and user-level requirements feed into the product requirements at the system level. The system

architecture then allocates requirements from the set of system requirements downward into the software,

hardware, and manual operations component [2].

Characteristics of good requirements [4]:

Characteristic Explanation

Unitary The requirement addresses one and only one thing.

Complete The requirement is fully stated in one place with no missing information.

Consistent The requirement does not contradict any other requirement and is fully consistent with all authoritative external documentation.

Atomic The requirement is atomic.

Current The requirement has not been made obsolete by the passage of time.

Unambiguous the requirement is concisely stated without recourse to technical jargon.

Verifiable The implementation of the requirement can be determined

Feasible The requirement can be implemented within the constraints of project.

Requirements Engineering Process:

1. Requirements Elicitation :

Software product development must begin by gathering the different kinds of requirements from suitable

stakeholders. The critical first step is to …

1.1. Define the Product‟s Business Requirements:

The business requirements should articulate how the product‟s developers and their customers will benefit

from this product, what the product could ultimately become, and the project‟s scope [5].

1.2. Get Extensive User Involvement:

Multiple studies indict insufficient user involvement as a common reason why software projects struggle

and fail. Every project should identify its distinct user classes and their characteristics. Users might differ

in their frequency of product use, features used, privilege levels, or skill levels.

1.3. Focus on User Tasks:

The use case approach is all the rage in software requirements circles these days and is one fad I endorse.

A use case describes a task the user must be able to perform with a software product. Use cases shift

requirements discussions from the traditional focus on features and functionality to the perspective of

what the user will do with the product. This change in perspective is more important than whether you

draw elaborate use case models [5].

1.4. Define Quality Attributes:

Quality attributes include characteristics that users can observe as well as those that are primarily

important to developers .Users might care immensely about system availability, efficiency, integrity,

reliability, robustness, and usability[5].

1.5. Elicitation techniques:

The choice of elicitation technique depends on the time and resources available to the requirements

engineer, and of course, the kind of information that needs to be elicited. We distinguish a number of

classes of elicitation technique:

Traditional techniques: These include the use of questionnaires and surveys, interviews, and analysis of

existing documentation such as organizational charts, process models or standards, and user or other

manuals of existing systems [5].

Group elicitation techniques: They include brainstorming and focus groups, as well as RAD/JAD

workshops (using consensus-building workshops with an unbiased facilitator) [6].

Prototyping: has been used for elicitation where there is a great deal of uncertainty about the

requirements, or where early feedback from stakeholders is needed [7].

Model-driven techniques: These include goal-based methods, such as KAOS [9] and [8], and scenario-based

methods such as CREWS [10].

Cognitive techniques: include a series of techniques originally developed for knowledge acquisition for

knowledge-based systems [11]. Such as protocol analysis, laddering, card sorting and repertory grids.

Contextual techniques: emerged in the 1990‟s as an alternative to both traditional and cognitive

techniques [12]. These include the use of ethnographic techniques such as participant observation. They

also include ethnomethodogy and conversation analysis, both of which apply fine grained analysis to

identify patterns in conversation and interaction [13].

2. Requirements Analysis:

Requirements analysis includes decomposing high-level requirements into detailed functional

requirements, constructing graphical requirements models, and building prototypes. Analysis models and

prototypes provide alternative views of the requirements, which often reveal errors and conflicts that are

hard to spot in a textual SRS. Another important analysis activity is to...

2.1. Prioritize Requirements

Any project with resource limitations must establish the relative priorities of the requested features, use

cases, or functional requirements. Prioritization helps the project manager plan for staged releases, make

trade-off decisions, and respond to requests for adding more functionality. Prioritization often becomes

politically and emotionally charged, with all stakeholders insisting that their needs are most important. A

better approach is to base priorities on some objective analysis of how to deliver the maximum product

value within the schedule, budget, and staff constraints [5].

3. Requirements Specification:

The most essential specification key practice is to write down the requirements in some accepted,

structured format as you gather and analyze them. The objective of requirements development is to

communicate a shared understanding of the new product among all project stakeholders. Historically, this

understanding is captured in the form of a textual SRS written in natural language, augmented by

appropriate analysis models [5].

4. Requirements Verification:

Verification involves evaluating the correctness and completeness of the requirements, to ensure that a

system built to those requirements will satisfy the users‟ needs and expectations. The goal of verification

is to ensure that the requirements provide an adequate basis to proceed with design, construction, and

testing. A powerful way to achieve this goal is to Inspect Requirements Specifications because it costs so

much more to fix defects later in the development process, formal inspection of requirements is perhaps

the highest leverage software quality practice available. Who have successfully implemented

requirements inspections find them to be tedious, slow, painful, and worth every minute because so many

defects are found so cheaply. Combining formal inspection with incremental informal requirements

reviews provides a powerful approach to building quality into your product [5].

Requirements Document Standards:

There are Several Standards for Requirements Documents exist [3]:

1- IEEE Standard 1362-1998.

Developed by IEEE, it presents a template that may be used to specify user requirements. The template

describes:

1- Current situation (without system).

2- Justification for change (why new system).

3- Description of proposed system (high level).

2 - IEEE Standard 830-1998 Developed by IEEE, it presents a template that may be used to specify developer requirements (some

times it is partially used to describe user developer requirements

as it contains parts that are on a higher level) .The template describes:

1- Overview of the system.

2- Justification for change (why new system).

3- Description of proposed system (high level).

3- Volere Template:

Developed by James & Suzanne Robertson (The Atlantic Systems Guild),it Presents a template that may

be used to specify user requirements as well as developer requirements:

1- Some template sections describe very detailed information about the system while other sections are

very high level (developer vs. user).

2- Some template sections can be used for a developer audience as well as auser audience.

In these cases either the used notation is the key differentiator or the information contained in the user

document is refined in the developer section.

Conclusion:

Many delivered systems do not meet their customers‟ requirements due, at least partly, to ineffective RE.

RE is often treated as a time-consuming, bureaucratic and contractual process. This attitude is changing as

RE is increasingly recognized as a critically important activity in any systems engineering process. The

novelty of many software applications, the speed with which they need to be developed, and the degree to

which they are expected to change, all play a role in determining how the systems development process

should be conducted. The demand for better, faster, and more usable software systems will continue, and

RE will therefore continue to evolve in order to deal with different development scenarios. We believe

that effective RE will continue to play a key role in determining the success or failure of projects, and in

determining the quality of systems that are delivered.

References:

1- Draft – Please do not circulate- chapter 1- What is Requirements Engineering- page 2.

2- Software Requirements Engineering: What, Why, Who, When, and How- By Linda Westfall.

3- Requirements Engineering- Standards Natural Language Requirements- -WS 2010/2011-Lecture-

by Jörg Dörr.

4- http://en.wikipedia.org/wiki/Requirement#Requirements_in_systems_and_software_engineering.

5- http://www.processimpact.com/articles/telepathy.html

6- Maiden, N. & Rugg, G. (1996). ACRE: Selecting Methods for Requirements Acquisition. Software

Engineering Journal, 11(3): 183-192.

7- Davis, A. (1992). Operational Prototyping: A New Development Approach. Software, 9(5): 70-78.

8- Chung, L., Nixon, B., Yu, E. & Mylopoulos, J. (2000). Non- Functional Requirements in Software

Engineering. Boston: Kluwer Academic Publishers.

9- Van Lamsweerde, A., Darimont, R. & Letier, E. (1998). Managing conflicts in goal-driven

requirements engineering. IEEE Transactions on Software Engineering, 24(11): 908-926.

10- Maiden, N. (1998). CREWS-SAVRE: Scenarios for Acquiring and Validating Requirements.

Automated Software Engineering, 5(4): 419-446.

11- Shaw, M. & Gaines, B. (1996). Requirements Acquisition. Software Engineering Journal, 11(3):

149-165.

12- Goguen, J. & Linde, C. (1993). Techniques for Requirements Elicitation. 1st IEEE International

Symposium on Requirements Engineering (RE'93), San Diego, USA, 4-6th January 1993, pp. 152-

164.

13- Viller, S. & Sommerville, I. (1999). Social Analysis in the Requirements Engineering Process:

from ethnography to method. 4th International Symposium on Requirements Engineering (RE'99),

Limerick, Ireland, 7-11th June 1999.