Inception & Evolutionary requirements

CHAPTER 4 & 5
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-of-magnitude

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 project’s 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
◦ A short executive summary document to quickly learn the project’s big ideas

Glossary
◦ Key domain terminologies, noteworthy terms
◦ Data dictionary (requirements related to data such as validation rules, acceptable values)

Risk list and risk management plan 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 Use-cases 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 stakeholder’s 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:
Implementation – resource limitations, languages, tools, hardware
Interface – constraints imposed by interfacing with external system
Operations – system management, operational settings
Packaging
Legal licensing

These requirements are mostly categorized as functional and nonfunctional

requirements
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