1. Requirements engineering is concerned with identifying user needs and communicating the purpose and context of a software system. 2. There are different levels and types of requirements including business, user, and system requirements. Good requirements are unitary, complete, consistent, unambiguous, and verifiable. 3. The requirements engineering process includes elicitation, analysis, specification, verification and documentation according to standards. Effective requirements engineering is critical for project success.

1. ‫بسم اهلل الرحمن الرحيم‬
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.

2. 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

3. 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:

4. 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

5. 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:

6. 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.