Inception & Evolutionary

CHAPTER
4&5
Requirements

Inception
In inception phase the following questions have been
explored
What is the vision and business case of this project?
Feasibility
Buy and/or build
Rough unreliable range of cost
Should we proceed or stop?
These requirements exploration helps in getting the order-ofmagnitude estimate. Since the requirements are not fully
defined a realistic estimate is not possible

Inception
The idea behind inception is to do just enough exploration to find
out the overall purpose and feasibility of the system to be
developed
It is the elaboration phase where the critical requirements and
risks are being handled
The inception phase should be relatively short
If it is longer than few weeks then the point of inception is being
missed

Oil business example

In the oil business when a new system is being
considered, some of the steps include:
Decide if there is enough evidence or business
case to even justify exploratory drilling
If so do measurements and exploratory drillings
Provide scope and estimate information
Oil extraction and refinement correcting
estimates

How long is inception

The duration of the inception phase depends on previous project
experience (if they have done similar projects in the past and
how things turned out to be)
Reliability (past experience or reviews) of the tools and
technologies being proposed
Since it is the initial step, therefore, the set of investigation and
artifacts it possess is small i.e may be 10% of the use cases
Some programming work may occur in inception to create
proof of concept prototypes, to clarify a few requirements
and/or to experiment for key technical questions

Vision and business case

High level goals
Constraints
Business case
A short executive summary document to quickly learn the projects big ideas
Use-case model
They are set of scenarios of using the system
Functional requirements
10% in detail
Supplementary specification
Identifying and defining non-functional requirements such as performance, licensing
Glossary
Key domain terminologies, noteworthy terms
Data dictionary (requirements related to data such as validation rules, acceptable values)
Risk list and risk management plan
Prototypes and proof of concepts
Iteration plan (for next elaboration)
Development case description of customized UP steps

Not all the artifacts are being produced and rather those which add value to the project,
while
drop the ones that does not prove its worth

UML in inception

The purpose of inception is to collect enough

information to establish a common vision
No UML diagramming is being carried out in this
phase
It has more focus on identifying critical requirements,
basic scope of the project and only 10% of the Usecases are described in detail

Evolutionary
requirements
Requirements are the capabilities and conditions to which
the system must confirm
Not trying to fully define all the requirements because of
the inevitably changing and unclear stakeholders wishes
Following a systematic approach to finding, documenting,
organizing and tracking the changing requirements
The requirements are being identified, analyzed,
programmed and tested through managed chain of steps
from most important to least important
According to a study 45% of the features specified at the
start of the project were never used while 19% of them
were being rarely used. Almost 65% of the features
specified earlier in waterfall model were of little or no value

Types of requirements
(FURPS+)
Functional requirements features, capabilities
Usability human factor
Reliability frequency of failure, recoverability,
predictability
Performance response time, throughput,
accuracy, availability, resource usage
Supportability adaptability, maintainability,
internationalization, configurability
+ is for the sub factors:

Natural Language
specification
Natural language has been used to document requirements
since the start of software engineering
It is expressive, intuitive and universal
On the other hand it is potentially vague, ambiguous and
its meaning depends on the background of the reader
As a result there are many proposals for alternative ways
for to write requirements
However, none of these have been widely adopted and
natural language continue to be used in specifying system
requirements

Guidelines for using Natural

Language
Invent a standard format and ensure that all
requirement definitions adhere to that format.
Standardizing will make requirements easy to
understand and to check with them e.g writing
each requirement in a single sentence on a
separate line. Attaching some information
with it to highlight why this requirement was
desired

Use language consistently to distinguish between

mandatory and desirable requirements. Mandatory
requirements are the one that the system must support
while the desired are the ones that that the system
shall support
Make use of highlighting e.g bold, italic or color to pick
out key parts of the requirements
Software requirements is a technical documents and do
not assume that users will understand it. Avoid using
abbreviations, acronyms and technical words

Requirements
Discovery
Interviewing:
Formal or informal interviews with system
stakeholders. In these interviews, questions
about software system in use and system to
be developed are asked

Close interviews: predefined set of questions

Open interviews: No agenda is followed and
a range of issues are being discussed

 Observation: The Requirements engineering team

or some of its members observe the real system
functions. In some cases their identity is kept
secret to get an honest view
Surveys: End users of the system can be surveyed
to find what they exactly want from the system and
how do they expect it to be
Face-to-face
Paper-based (by post)
Online
Via phone