Phase 1 of Unified Process Life cycle - Inception

Unified process like any other process has got some phases through which the whole development process takes place. The unified process follows through the following 4 steps:

1. Inception
2. Elaboration
3. Construction and
4. Transition

Throughout this whole article we are going to discuss in detail the first phase of the unified process i.e., the inception phase. So let us a take a deep dive in to the understanding of the first phase “inception” of the project life cycle.

What is an Inception Phase

- The inception phase to say is usually short in most of the development cases but in some rare cases it can be quite lengthy. 

- But in an ideal project it is advisable to keep it short and simple other wise it will be required to divide in to much smaller iterations which in turn will be a complete waste of time.

- Furthermore a lengthy inception phase may indicate that there is an excess of up front specification which is something that is not in accordance with the principles of the unified process. - Every phase of the unified process has some pre defined goals that are needed to be satisfied in that phase itself. 

Goals defined for Inception Phase

- For inception phase the below mentioned goals have been defined:

1. To define and establish a scope for the software project.
2. To establish boundary conditions for the software project.
3. To establish a justification for developing the software system or application.
4. To outline the use cases for driving the design trade offs.
5. To outline the key requirements for the same purpose as the use cases.
6. To outline all the architectures those are to be implemented in the process.
7. To identify the associated risks.
8. To prepare a preliminary project schedule.
9. To estimate the cost of the whole software project.

When all of these mentioned goals are established then the inception phase is said to be concluded and completed. 

In short, what is inception phase is all about?

- The inception phase is all about developing a close enough vision of the software project, defining its scope and making the business case and providing an approximate estimate of the schedule and cost for the whole development project. 

- The inception phase seeks to build concurrence among all the stake holders involved in the development process on the basis of the objectives. 

- In an overall sense, the inception phase determines the feasibility of the solution that has been intended to build the software system or application. 

- In a way it helps the developers to understand what to build and risks associated with the project. - Another advantage is that the key system functionality can be easily recognized. 

- Due to some reasons the developers may be forced to have more than one iterations in the inception phase. 

- The possible reasons can be:

1. The project is so large that it is difficult to define its scope.
2. The system is unprecedented.
3. There are too many stake holders with complex relationships and competing needs.
4. Creation of proof of concept or prototype is required by the major technical risks involved.

- Over the inception phase sometimes counter productive patterns are observed. 

- In such situation a team may postpone providing estimate until the whole domain has been analyzed and documented. 

- But such behavior can lead to a condition called “analysis paralysis”. 

- Even the poor planning of the iterations of the inception phase can make the whole process go awry. 

- This can be avoided only if the iterations have been planned in such a way that they are risk driven and have been integrated and tested earlier. 

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.

Introduction to Unified Process - Different stages in Unified Process

The Unified Process is a use-case driven, architecture-centric, iterative and incremental software process designed as a framework for UML methods and tools. The Unified Process is an incremental model in which five phases are identified:

- Inception Phase
It encompasses both customer communication and planning activities and emphasizes the development and refinement of use cases as a primary model. Incremental nature of the ensuing project is developed. In general, a use-case describes a sequence of actions that are performed by an actor as the actor interacts with software.

- Elaboration Phase
It encompasses the customer communication and modeling activities focusing on the creation of analysis and design models with an emphasis on class definitions and architectural representations. Elaboration refines and expands the preliminary use cases that were developed as part of inception phase and expands the architectural representation to include five different views of software - use case model, analysis model, design model, implementation model and deployment model.

- Construction Phase
It refines and then translates the design model into implemented software components. To accomplish this, analysis and design models started during elaboration phase are completed to reflect the final version of software increment.

- Transition Phase
It transfers the software from the developer to the end user for beta testing and acceptance. The software team creates the necessary support information that is required for release. At the end of this phase, the software increment becomes a reusable software release.

- Production Phase
In this, it is an on-going monitoring and support are conducted. This phase coincides with the deployment activity of generic process.

It is possible that work may have already begun on next software increment at the same time when the construction, transition, and production phases are conducted.

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.