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 goalsConstraints

Business caseA short executive summary document to quickly learn the project’s big ideas

Use-case model◦◦◦

They are set of scenarios of using the systemFunctional requirements10% in detail

Supplementary specification◦ Identifying and defining non-functional requirements such as performance, licensing

Glossary◦◦

Key domain terminologies, noteworthy termsData 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 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:

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 Guidelines for using Natural LanguageLanguage

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