Faculty Of Computing And Information

Management
Masters In Information System Management
Business Process Management

Term Paper

Reg. No

Name

KCA/14/02515

Muthiani Muoka

Lecture: Prof .William Ddembe

Table of Contents
1.

Abstract. .............................................................................................................................................................3

2.

Introduction. .......................................................................................................................................................3

3.

Background. ........................................................................................................................................................4
3.1

Definition . ..................................................................................................................................................4

3.2

User Requirements. ....................................................................................................................................4

3.3

System Requirements.................................................................................................................................5

3.3.1

Functional Requirements ...................................................................................................................5

3.3.2

Non-Functional Requirements. ..........................................................................................................5

4.

Definitions of the Terms. ....................................................................................................................................6

5.

Significant of the paper(theme). ........................................................................................................................7

5.1

6.

Objectives of Software Engineering. ..........................................................................................................7

Literature Review on Requirements Process Models ........................................................................................7

6.1

Waterfall model. .........................................................................................................................................8

6.2

Iteration model. ..........................................................................................................................................8

6.3

V-shaped model..........................................................................................................................................9

6.4

Spiral model. ............................................................................................................................................ 10

6.5

Extreme model. ....................................................................................................................................... 11

7.

Critique of literature. ....................................................................................................................................... 12

8.

Conclusion. ...................................................................................................................................................... 13

9.

Reference......................................................................................................................................................... 15

1.

Abstract.

Software Requirements Engineering is the initial step of software development activity in which the
requirements from the customer are elicited and documented. the main aim of requirements Engineering
is gather the requirements. Set of activities are involved such as feasibility study, elicitation analysis and
management. there are many method which can be employed to gather the requirements lack of enough
knowledge of the results of each method and method affects the software quality and cost of production.
Requirements Engineering is a process which continues till the project is complete. This paper presents
the literature study and the experimental case study on analyzing and compare different methods for
requirements gathering process.

2.

Introduction.

Requirements engineering is the most crucial phase in software development as the other phases in
software development depends on it. It's meant to cover all the activities involved. the success of a
software system is the percentage to which it addresses the requirements or the purpose for which it was
intended. so, Software Requirements Engineering is the process is discovering that purpose, by
identifying stakeholders and their needs and documenting these in a form that is amenable to analysis,
communication and implementation.

In system engineering. Requirements engineering is the science and discipline concerned with analyzing
and documenting requirements. It comprises needs analysis, requirements analysis, and requirements
specifications. In other words, Software Requirements Engineering

means that requirement for a

system are defined, managed and tested systematically.

Stakeholders (including paying customers, users and developers) may be numerous and distributed.
Their goals may vary and conflict, depending on their perspectives of the environment in which they
work and the tasks they wish to accomplish. [1]

Requirements are generally generated form or by multiple stakeholders from different organizations and
different

operating environments where people work. therefore, requirements can be technical or

functional.
Introducing requirements engineering is a change of behavior and culture and not just a change of
process and technology. It is also important that the cost of fixing a requirements defect later in the
development stage is much higher than the cost of
identifying and fixing it in the early stages of development. In order to do this the system requirements
must be properly identified, analyzed and reviewed early in the development process.
Requirements engineering is such a process that focuses on discovering, analyzing, documenting and
managing system requirements. Several processes and techniques have been developed to assist
requirements engineering activities. [2]

3. Background.
3.1 Definition .
Software 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 behaviors and their evolution over and across software
families.[3]
Requirements specify the services that should be provided by the system, the method in which they
should be provided and constraints in providing these services. requirements form the first phase in the
software lifecycle . requirements are the things we discover early stages of the software development life
cycle. the gathered requirements describe how the system will behave, system domain, user level
facilities and the constraints on which the system should be operated. [4]
There are 2 main types of these requirements , which will be described below:

3.2 User Requirements.

user requirements describe the expected services from the system, constraints on archiving them and the
way the system provides the requirements. It is written in way that is everyone can understand without

any technical knowledge or background knowledge. the requirements are defines by the use of external
activities and behaviors of the system and never defined based on system design or implementation.
Statements in natural language plus diagrams of the services the system provides and its operational
constraints. Written for customers.[5]

3.3 System Requirements.

system requirements provide the internal knowledge of the user requirements .they form the basic
principal that should be followed to design the system architecture.. the developer analyze the
requirements to exactly know what has been implemented or suggested in the system. these is essential
to be able to sign an agreement to implement the system. system requirements are classified into 2:
A structured document setting out detailed descriptions of the systems functions, services and
operational constraints. Defines what should be implemented so may be part of a contract between client
and contractor.

3.3.1

Functional Requirements

Statements of services the system should provide, how the system should react to particular inputs and
how the system should behave in particular situations.
these are the functions or services that define :

what the system is expected to provide.

how the system should respond or react to particular input or output.

what the system should not do (error).

the constraints encountered while implementing the mentioned requirements.

3.3.2

Non-Functional Requirements.

Constraints on the services or functions offered by the system such as timing constraints, constraints on
the development process, standards, security requirements, performance, etc. The defines the
effectiveness of the functions provided by the system. they affect the functions provided by the system .
any system that does not provide a reliable service and also security measures against any threats will be

considered

a success. these requirements form

the basic quality of the system. Non-functional

requirements include :

4.

security measures provide by the system.

efficiency of the system.

integrity of the system.

cost effectiveness of the system.

Definitions of the Terms.

The term requirement engineering is used to describe a systematic process of developing requirements
through an iterative, co-operative process of analyzing the problem, documenting the resulting
observations in a variety of representation formats, and checking the accuracy of the understanding
gained. [7]
Requirement engineering process, is the other key term used to describe the decomposition of RE into
interacting non linear activities. These proceed from informal, fuzzy individual statements of
requirements to a formal specification that is understood and agreed by all stakeholders. The final term
requirements engineering effectiveness is used as the measure of the accuracy and completeness of
achievement of the process goals.

Requirements management play important role in success of software. It manages changes to

requirements and maintains traceability in requirements documents. Requirements can be written using
quality attributes known as software requirements specification. Success rate of product depends on
process used by organization. Every company needs to assess their present approach in order to remain
competent in dynamic market.[8]

5.

Significant of the paper(theme).

The goal of Software Requirements Engineering is to systematically develop and manage a set of
evolving requirements to specify the properties of a software system that addresses a real-world problem
or opportunity. The discovery, representation and verification of requirements are inherently complex
processes but are critical aspects of successful software design and development. [9]
This paper work provides an overview of requirements management in a systems engineering. It
provides a detailed look at requirements and techniques supporting it. it outlines an action plan for
improving the management of requirements in an industrial organization.

5.1

Objectives of Software Engineering.

1.

To introduce the concepts of user and system requirements.

2.

To describe functional and non-functional requirements.

3.

To explain how software requirements may be organized in a requirements document.

4.

To describe the principal requirements engineering activities and their relationships.

5.

To introduce techniques for requirements elicitation and analysis.

6.

To describe requirements validation and the role of requirements reviews.

7.

To discuss the role of requirements management in support of other requirements engineering

processes.

6.

Literature Review on Requirements Process Models

A software process model is an abstract representation of a process. It presents a description of a

process. This paper illustrates an important issue in Software Requirements Engineering. It is concerned
with the software management processes that examine the area of software development through the
development models, which are known as software development life cycle. It represents five of the
development models:[10]

6.1

Waterfall model.

The waterfall model is the classical model of software engineering. this model emphasizes planning in
early stages, it ensures design flaws before they develop.
Plan-driven model. Separate and distinct phases of specification and development. [11]

Figure 1: Waterfall model

6.2

Iteration model.

In Iterative Development Model, the project is divided into small parts. When each of them is finished, it
can be demonstrated to customers and feedbacks from customers are collected. Thus enable users to
have some functionality while the rest is being developed. In a variation of this model, the software

products, which are produced at the end of each step (or series of steps), can go into production
immediately as incremental releases. [13]

Figure 2: Iteration model

6.3

V-shaped model.

the V-Shaped life cycle is a sequential path of execution of processes. Each phase must be completed
before the next phase begins. Testing is emphasized in this model more than the waterfall model. The
testing procedures are developed early in the life cycle before any coding is done, during each of the
phases preceding implementation. [14]

Figure 3 : V-shaped model

6.4

Spiral model.

The spiral model is similar to the incremental model, with more emphases placed on risk analysis. The
spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation. A software project
repeatedly passes through these phases in iterations (called Spirals in this model). The baseline spiral,
starting in the planning phase, requirements are gathered and risk is assessed.
Each subsequent spiral builds on the baseline spiral. Requirements are gathered during the planning
phase. In the risk analysis phase, a process is undertaken to identify risk and alternate solutions. A
prototype is produced at the end of the risk analysis phase. Software is produced in the engineering
phase, along with testing at the end of the phase. The evaluation phase allows the customer to evaluate
the output of the project to date before the project continues to the next spiral.
In the spiral model, the angular component represents progress, and the radius of the spiral represents
cost. [15]

Figure 4 : Spiral model.

6.5

Extreme model.

It relies on constant code improvement, user involvement in the development team and pair wise
programming . It can be difficult to keep the interest of customers who are involved in the process.
Team members may be unsuited to the intense involvement that characterizes agile methods. [15]

Figure 5 : Extreme model

7.

Critique of literature.

This study should be considered with reference to the contexts of the projects.
Definitive generalizations about companies not included in the research cannot be made, due to its small
sample size. Additionally, many industries have not been represented in this study.
Argument may be raised that the participants of the research may not actually have done what they
indicated was done. While honest answers were encouraged, it cannot be known whether this occurred
and the answers were taken at face value. The process models were constructed from the data gathered
in the questionnaire. The perceptions and interpretations of different people about the Software
Requirements Engineering process may differ between people, as was discovered from the results of the
two participants in project A3. It is also possible that the results may not have identified all instances of
iterations of activities. Therefore, the process models must be considered as high-level representations of
the Software Requirements Engineering process from one perspective.
As this research is essentially an exploratory study, there are many opportunities for further research in
this area. This study could be expanded to include a wider spectrum of industry and projects of different
customer-supplier relationships. Results could be gathered

from other roles within the project team, such as the developers, to identify whether the process is
perceived differently from other perspectives. Participants could also be involved in the process of
comparing the companys Software Requirements Engineering process models to those from literature.
Future studies could attempt to correlate the use of different RE process models with project success.
Additionally, the relationships between explicit and implicit activities and project success could also be
studied to identify if there is a link between the nature of activities and the success of the RE process.
This research could also lead into the area of Software Requirements Engineering

process

improvement, by identifying areas of strength and weakness in current Software Requirements

Engineering processes.

8.

Conclusion.

This paper proposes software requirement engineering classification to improve the process of managing
requirements. Software Requirements Specification help in documenting requirements in better way as
collection of requirements is a crucial phase in software development.
The requirements engineering processes model selection is very much important task and it must
be related with the size, complexity, costs, budges of the project.
The most common, most serious problems associated with software development are related to
requirement analysis. Begin from the term definition, we discussed the requirements engineering and its
dimension. And finally, we analyzed the requirement engineering practices and give the importance of
requirement engineering practices for designing quality software products from several viewpoints.
After completing this research , it is concluded that :
1.

There are many existing models for developing systems for different sizes of projects and

requirements.
2.

Requirements engineering is a key component of system development processes.

3.

If we pay attention to requirements, we reduce later problems in system development and

operation.
4.

Requirements engineering will always be difficult because the requirements are reflections of a

rapidly changing business environment.

5.

Traditional requirements engineering processes will have to evolve for new types of software

system and business needs.

6.

These models were established between 1970 and1999.

7.

Waterfall model and spiral model are used commonly in developing systems.

8.

Each model has advantages and disadvantages for the development of systems , so each model

tries to eliminate the disadvantages of the previous model.

9.

Future work

Software simulation

Web-based software engineering

Software process reengineering .

9. Reference.
[1] Bashar Nuseibeh, Steve Easterbrook, :Requirements Engineering: A Roadmap page 1, sep 2000.
[2] Kullor, Requirement engineering for Software Products, The University of Carlag, Canada, pp.
1-12, 2011.
[3] Bashar Nuseibeh, Steve Easterbrook :Requirements Engineering: A Roadmap page 35-46 sep
2000.
[4] Maiden, N. & Ruggs (1996). ACRE: " Selecting Methods for requirements Acquisition". IEEE,
Software Engineering Journal, 11(3): 183-19247.
[5] Somerville: "software engineering". 8th edition, addition Wesley.
[6] Neil Maiden: " user requirement and system requirements " city university of London, IEEE
publications, volume 25, issue 2, April 2008, pages 90-91.
[7] Pohl, The Three Dimension of Requirement Engineering, Proc. Of International Conference on
advanced information System Engineering, pp. 275-292.
[8] Dhirendra Pandey & Vandana Pandey , Importance of Requirement Management A
Requirement Engineering Concern : pages. 2-3.
[9] http://www.aut.ac.nz/study-at-aut/study-areas/computer-mathematical-sciences/researchgroups/software-engineering-research-laboratory-serl/overview/requirements-engineering.
[10]

Nabil Mohammed Ali Munassar, A. Govardhan: A Comparison Between Five Models Of

Software Engineering : Page 2 September 2010.

[11]

Nabil Mohammed Ali Munassar, A. Govardhan: A Comparison Between Five Models Of

Software Engineering : Page 3 September 2010.

[12]

Nabil Mohammed Ali Munassar, A. Govardhan: A Comparison Between Five Models Of

Software Engineering : Page 4 September 2010.

[13]

Nabil Mohammed Ali Munassar, A. Govardhan: A Comparison Between Five Models Of

Software Engineering : Page 5 September 2010.

[14]

Nabil Mohammed Ali Munassar, A. Govardhan: A Comparison Between Five Models Of

Software Engineering : Page 6 September 2010.

[15]

Nabil Mohammed Ali Munassar, A. Govardhan: A Comparison Between Five Models Of

Software Engineering : Page 7-8 September 2010.