What is evolutionary requirements analysis?

Requirements analysis is of many types depending up on which development process or methodology is being followed. This article has been written about a type of requirements analysis known as “evolutionary requirements analysis”. But, before going on to the main discussion we will first brief up ourselves with the concepts of a general requirements analysis.

WHAT IS REQUIREMENTS ANALYSIS?

- Requirements analysis is a means of encompassing the tasks that are used in the determination of the conditions and the needs of the new software system or application under development.

- Even the various requirements of the stake holders that conflict with each are taken in to account in the requirements analysis.

- The stake holders here can be either the users or the beneficiaries.

- Requirements analysis actually fall under the category of the requirements engineering but it is a common and frequent requirement of all the other branches of the engineering.

- It encompasses with the below mentioned activities:
1. Eliciting
2. Analyzing
3. Documenting
4. Validating
5. Management of the software system

- With a proper requirements analysis only a proper base version of the software system or application can be created which other wise would be an impossible job.

- For a requirement of the software system or application to be taken in to consideration under the requirements analysis it should possess the below mentioned characteristics:
1. It should have been documented.
2. It should be actionable and active.
3. It should be measurable.
4. It should be traceable by the testing methodologies
5. It can be related to the identified business opportunities, activities or needs.
6. It should have been sufficiently defined with details for the designing of the software system or application.

If we see concept wise, three major activities are involved in any requirements analysis which are:

1. Eliciting Requirements
This activity is involved with the identification of the various kinds of requirements that have been derived from several sources like:
(a) Business process documentation,
(b) Project documentation
(c) Project charter,
(d) Interviews of the stake holders,
(e) User stories and so on.
This step is often known as the “requirements gathering”.

2. Analyzing Requirements
This step is involved with the determination of the level of correctness of the stated requirements in the requirements list on the grounds of the following factors:
(a) Clarity
(b) Completeness
(c) Consistency
(d) Unambiguity
(e) Resolution of any apparent conflicts and so on.

3. Recording Requirements
This step is involved with the documentation of the requirements in various forms like:
(a) Summary list
(b) Natural language documents
(c) User stories
(d) Use cases
(e) Process specifications and so on.

EVOLUTIONARY REQUIREMENTS ANALYSIS

- Requirements analysis is quite a time consuming as well as an arduous process for which many types of psychological skills have to be exercised.

- With the new environment, changing of the requirements and the stake holders is obvious, and so it becomes extremely important to keep the requirements updated by identifying the needs of the stake holders.

- It should also be determined that up to what level did the stake holders understood the implications of the program.

- The evolutionary requirements analysis is often abbreviated to “ERA”.

- As the term itself states, the evolutionary computing techniques are used in the automatic selection of the machine and human agents in the model of the software system so as to match the requirements which are non functional.

- The aspects such as the performance, reliability and cost of many different software systems are analyzed via the execution of the model variants along with the scenarios.

- Out of all, the software systems which perform better are selected in order to obtain an optimal solution.

Eliciting Requirements - what are basic requirements for Quality Function Deployment ? PART 2

Quality function deployment defines requirements in a way that maximizes the customer satisfaction. Quality function deployment is used to translate customer requirements to engineering specifications. It is a link between customers, design engineers, competitors and manufacturing. QFD is important as it gives importance to the customer and put these values in engineering process. There is a proper time to use quality function deployment. It is used in early phases of design. It can also be used as a planning tool as important areas are identified.

Quality function deployment contains four phases:
- product planning
- product design
- process planning
- production planning

The benefits of QFD includes better understanding of customer needs, reduces iterations in design and enhancing teamwork. There are three types of requirements that are defined by QFD:
- Normal requirements are a mirror of objectives that are stated for a product during meetings with the customer. Normal requirements include graphical displays,specific system levels.
- Expected requirements are requirements that are fundamental and customer does not explicitly state them but their absence will create a significant dissatisfaction. These include ease of software installation and human/machine interaction etc.
- Exciting requirements are the requirements that do not fall within customer's expectations but are very satisfying when they are present.

Eliciting Requirements - what are basic guidelines for conducting collaborative requirements gathering meeting? PART 1

For collaborative requirements gathering, stakeholders and developers work together to identify the problem, propose a solution and negotiate approaches. The basic guidelines include:
- software engineers and customers attend meetings.
- rules for preparation and participation are established.
- agenda that covers important points and encourage free flow of ideas.
- meeting is controlled by a facilitator who can be a customer, developer or an outsider.
- worksheets, wall stickers, chat room etc. are used.
- goal is to identify the problem, propose a solution and negotiate approaches.

If a system or product will serve many users, one should be certain that requirements are elicited from representative cross-section of users. If only one user defines all requirements, acceptance risk is high. As requirements gathering meeting begins, the first point of discussion is need and justification of the new product. Once agreement is established, each participant presents his lists for discussion in one particular area. After this, combined list is prepared by group after which facilitator coordinates discussion.
Avoid the impulse to shoot down a customer's idea as "too costly" or impractical. The idea is to negotiate a list that is acceptable to all.

Once the lists are completed, team is divided into sub teams and each works to develop mini specifications. Additions, deletions and elaborations are made. After this, each attendee makes a list of validation criteria and finally one or more participant is assigned the task of writing a complete draft specification.

Requirement Model - Obtained during Elaboration phase

During elaboration, the information that is obtained from inception and elicitation are refined and expanded to produce two models:
- Requirements Model
- Analysis Model

The requirement model provides a model of the system or problem domain. It consists of three things:

Use Case Model
Use case model describes what the system does. It serves as a contract between the customers, end users and developers. The Use CaseModel consists of two parts, namely, the use case diagrams and use case specifications.
The use case diagram shows the functionality that the system provides and which users will communicate with the system. It consists of actors and use cases.
The use case specifications are textual documents that specify properties of the use cases.

Supplementary Specifications
Requirements that do not map to a specific use case are part of supplementary specifications. These requirements may be non functional or system constraints. Non functional requirements includes maintainability of the source codes, usability, reliability, performance, and supportability. System constraints restricts our choices for constructing a solution.

Glossary
It defines a common terminology for all models. This is used by the developers to establish a common dialect with customers and end-users.

What are concepts of Requirements Engineering? Different tasks of requirement engineering - Inception and Elicitation.

Requirement Engineering encompasses a set of tasks that lead to an understanding of what the business impact of the software will be, what the customer wants, and how end-user will interact with the software. The basic agreement between end-users and developers on what the software should do is given by requirement engineering.

It gives stakeholders anopportunity to define their requirements understandable to the development team. Designing and building an elegant computer program that solves the wrong problem is a waste. This is the reason why it is important to understand what customer wants before one begins to design and build a computer-based system. Requirements Engineering builds a bridge to design and construction.

There are seven distinct tasks to requirements engineering namely inception, elicitation, elaboration, negotiation, specification, validation and management.

INCEPTION

At inception, the problem scope and its nature is defined.
To initiate requirement engineering, steps include:
- identify stakeholders.
- recognize multiple viewpoints.
- work towards collaboration.
- ask the first question.
The main output or work product of inception task is a one or two pages of
product request which is a paragraph summary of the problem and its nature.

Elicitation

Elicitation is a task that helps the customer define what is required. The problems encountered are problems of scope, problems of understanding, problems of volatility. Elicitation makes use of a requirements elicitation format that combines the elements of problem solving, elaboration, negotiation, and specification.
Joint Application Development is one collaborative requirement gathering technique that is popularly used to elicit requirements.
The tasks involved in elicitation can be categorized into three groups, namely, pre-joint meeting tasks, joint meeting tasks and post-joint meeting tasks.

Quality Function Deployment is a technique that emphasizes an understanding of what is valuable to the customer. It identifies three types of requirements normal requirements, expected requirements and exciting requirements.

The output of the elicitation task can vary depending on size of thesystem or product to be built. For most systems, the output or work products include a statement of need and feasibility, a bounded statement of scope for the system or product, a list of customer, users, and other stakeholders who participated in requirements elicitation, a description of the system's technical environment and a priority list of requirements, preferably, in terms of functions, objects and domain constraints that apply to each.

Requirements Engineering Tasks

Requirements Engineering :
* Provides a solid approach for addressing challenges in software project.
* Must be adapted to the needs of the: Process, project and product and the people doing the work.
* Begins during the communication activity and continues into the modeling activity.
* Helps software engineers to better understand the problem they will work to solve.

Requirements Engineering Tasks :
- Inception
* A task that defines the scope and nature of the problem to be solved.
* Software engineers ask context-free questions.
* Intent is to establish a basic understanding of the problem, the people who want a solution, nature of the solution that is desired and the effectiveness of preliminary communication and collaboration between the customer and the developer.

- Elicitation
Ask the customer, the users and others about the objectives of the system, what is to be accomplished, how the system of product fits into the needs of the business and finally, how the system or product is to be used on a day-to-day basis.
Why Elicitation is Difficult?
* Problems of scope.
* Problems of understanding.
* Problems of volatility.

- Elaboration
* Basic requirements (obtained from the customer during inception and elicitation) are refined and modified.
* Focuses on developing a refined technical model of software functions, features and constraints..
* Driven by the creation and refinement of user scenarios.
* End-result: analysis model that defines the informational, functional and behavioral domain of the problem.

- Negotiation
* There’s no winner and loser in an effective negotiation.
* Customers usually ask for more rather than what can be achieved.
* Some proposed conflicting requirements.
* The requirements engineer must reconcile these conflicts through a process of negotiation.

- Specification
* It can be written document, a set of graphical models, a formal mathematical model,a collection of usage scenarios,a prototype,or any combination of these.
* It is the final work product produced by the requirements engineer.
* It serves as the foundation for subsequent software engineering activities.
* It describes the function and performance of a computer-based system and the constraints that will govern its development.

- Validation
* Work products produced are assessed for quality in this step.
* A task which examines the specification to ensure that all software requirements have been stated unambiguously.
* That inconsistencies, omissions and errors have been detected and corrected.
* That work products conform to the standards established for the process, project and the product.