<< Chapter < Page Chapter >> Page >

Iterative nature of the requirements process

There is general pressure in the software industry for ever shorter development cycles, and this is particularly pronounced in highly competitive market-driven sectors. Moreover, most projects are constrained in some way by their environment, and many are upgrades to, or revisions of, existing software where the architecture is a given. In practice, therefore, it is almost always impractical to implement the requirements process as a linear, deterministic process in which software requirements are elicited from the stakeholders, baselined, allocated, and handed over to the software development team. It is certainly a myth that the requirements for large software projects are ever perfectly understood or perfectly specified.

Instead, requirements typically iterate towards a level of quality and detail which is sufficient to permit design and procurement decisions to be made. In some projects, this may result in the requirements being baselined before all their properties are fully understood. This risks expensive rework if problems emerge late in the software engineering process. However, software engineers are necessarily constrained by project management plans and must therefore take steps to ensure that the “quality” of the requirements is as high as possible given the available resources. They should, for example, make explicit any assumptions which underpin the requirements, as well as any known problems.

In almost all cases, requirements understanding continues to evolve as design and development proceeds. This often leads to the revision of requirements late in the life cycle. Perhaps the most crucial point in understanding requirements engineering is that a significant proportion of the requirements will change. This is sometimes due to errors in the analysis, but it is frequently an inevitable consequence of change in the “environment”: for example, the customer’s operating or business environment, or the market into which software must sell. Whatever the cause, it is important to recognize the inevitability of change and take steps to mitigate its effects. Change has to be managed by ensuring that proposed changes go through a defined review and approval process, and, by applying careful requirements tracing, impact analysis, and software configuration management. Hence, the requirements process is not merely a front-end task in software development, but spans the whole software life cycle. In a typical project, the software requirements activities evolve over time from elicitation to change management.

Change management

Change management is central to the management of requirements. This topic describes the role of change management, the procedures that need to be in place, and the analysis that should be applied to proposed changes. It has strong links to the Software Configuration Management KA.

Requirements attributes

Requirements should consist not only of a specification of what is required, but also of ancillary information which helps manage and interpret the requirements. This should include the various classification dimensions of the requirement and the verification method or acceptance test plan. It may also include additional information such as a summary rationale for each requirement, the source of each requirement, and a change history. The most important requirements attribute, however, is an identifier which allows the requirements to be uniquely and unambiguously identified.

Requirements tracing

Requirements tracing is concerned with recovering the source of requirements and predicting the effects of requirements. Tracing is fundamental to performing impact analysis when requirements change. A requirement should be traceable backwards to the requirements and stakeholders which motivated it (from a software requirement back to the system requirement(s) that it helps satisfy, for example). Conversely, a requirement should be traceable forwards into the requirements and design entities that satisfy it (for example, from a system requirement into the software requirements that have been elaborated from it, and on into the code modules that implement it).

Measuring requirements

As a practical matter, it is typically useful to have some concept of the “volume” of the requirements for a particular software product. This number is useful in evaluating the “size” of a change in requirements, in estimating the cost of a development or maintenance task, or simply for use as the denominator in other measurements.

Requirement measurements

Questions & Answers

Text editor project in c++
Ayesha Reply
hi daddy
Sreenu
hello sir
Ranjith
are unmanned flying machines that are built and equipped with various kinds of software systems that allow them to see, hear, and act. Discuss some of the societal challenges of building such kinds of systems.
johni Reply
You have developed a prototype of a software system and your manager is very impressed by it. She proposes that it should be put into use as a production sys tem, with new features added as required. This avoids the expense of system dev immediately useful. Write a short report for your manager expl
johni
You have developed a prototype of a software system and your manager is very impressed by it. She proposes that it should be put into use as a production sys tem, with new features added as required. This avoids the expense of system dev immediately useful.
johni
You have developed a prototype of a software system and your manager is very impressed by it. She proposes that it should be put into use as a production sys tem, with new features added as required. This avoids the expense of system dev immediately useful.
johni
You have developed a prototype of a software system and your manager is very impressed by it. She proposes that it should be put into use as a production sys tem, with new features added as required. This avoids the expense of system dev immediately useful. Write a short report for your manager expl
johni
You have developed a prototype of a software system and your manager is very impressed by it. She proposes that it should be put into use as a production sys tem, with new features added as required. This avoids the expense of system dev immediately useful.
johni
what is cocomo ?
Surabhi Reply
?
StReeT
give me coding of these projects
Aman Reply
feasibility study&fact gathering techniques
Nachi Reply
write about software engineering
Mandala Reply
8.10.0.
BARBU
define iterative model. example of iterative model. advantages and disadvantages of iterative model. when to use iterative model
Okello Reply
What is DFD in Software engineering
Hamid
i try out in netbeans this code:public class Profile { private Profile(int w) { // line 1 System.out.println(w); } public final Profile() { // line 5 System.out.println(10); } public static void main(String args[]) { Profile obj = new Profile(50); } } It is the question 5, and the answer is 50
Jacqueline Reply
how to join conversation
Bablu
i need help....Discuss the factors that influence the choice of the software development methodology to use when implementing software projects?(20)
tatenda Reply
The success rate of software development projects can be increased by using a methodology that is adequate for the specific characteristics of those projects.  then the focus on RAD,XP,RUP.
Hemant
hemant hie...it is a presentation i am working on...can you help me wth the introduction....please a powerful one hahahahha
tatenda
yes
Hemant
Define and show all Dipthongs and vowels used in english phonetics
Okendro Reply
what is the software engineering
Axmed Reply
please
Jennifer
hhahhaha
martin
software engineering is a organized process of activities for development a use full software . it may consist of : 1:spcecification 2:design 3: implementation 4: evolution:
hamayun
Please how can I create an application?
Eric Reply
please how can I create an application
Nchor
How do we create a software
Florence Reply
give a more direct question
Louis Reply
what is semantics?
amjad
what r the computer codes
Kawuba Reply
machine code, source code , object code, and byte code etc
Hemant

Get the best Software engineering course in your pocket!





Source:  OpenStax, Software engineering. OpenStax CNX. Jul 29, 2009 Download for free at http://cnx.org/content/col10790/1.1
Google Play and the Google Play logo are trademarks of Google Inc.

Notification Switch

Would you like to follow the 'Software engineering' conversation and receive update notifications?

Ask