Requirement engineering & Requirement tasks/Management. 1Prepared By:Jay A.Dave

Prepared By:Jay A.Dave. 1

Requirement engineering & Requirement tasks/Management.


INTRODUCTION

Requirement engineering helps software engineer to better understand the problem they will work to solve which consist of the set of tasks that lead to an understanding of what the business impact of the software will be. what the customer wants and how the end user will interact with the software.


INTRODUCTION

• Software engineers sometime refer as system engineer or analyst in the IT world, and this is the duty of him/her.

• This is most required as designing and building the most elegant program that solves wrong problem serves no one’s needs and that is why it is important to know what customer wants before one begin to design and code computer based systems.


INTRODUCTION

• Now it is very much important to know the steps involved in the process so the very first step begins with the inception which is the task that helps the customers to define what is required and there it has to be elaborated where basic requirements are fined and modified As the customer defines the problem.


Inception

• software engineers use context-free questions to establish a basic understanding of the problem, the people who want a solution, the nature of the solution, and the effectiveness of the collaboration between customers and developers). How does the software project get started?


Inception

• Is there a single event that catalyst for new computer based system or product, or does the need evolve over time? There is no definitive answer for such question.

• In some cases a casual conversation is all that is needed to participate a major software engineering effort, in general, most projects begin when a business need is identified or a potential new market or service is discovered.


Inception• Stakeholders from the business community define

business case for the idea, try to identify the breadth and depth of the market, do a rough feasibility analysis , and identify a working description of the projects scope. All of this information is subject to change.

• At project inception software engineering ask a set of context-free question. The intent is to establish a basic understanding of the problem, the people who want a solution, the nature of the solution that is desired , and the effectiveness of preliminary communication and collaboration between the customer and developer.


Elicitation• find out from customers what the product objectives are,

what is to be done, how the product fits into business needs, and how the product is used on a day to day basis).

• certainly seems simple enough- ask the customer, the users , and others what the objective for the system or product are, what is to be completed, how the system or product fits in to the needs of business and finally how the system or product is to be used on day-to-day basis. But it isn’t simple enough. There are few important facts about requirement elicitation.


Elicitation• Problem of scope: the boundary of the system is ill-defined or

the customers/users specify unnecessary technical details that may confuse, rather than clarify overall system objectives.

• Problem of understanding: the customer/users are not completely sure of what is needed, have a poor understanding of the capabilities and limitations of their computing environment, do not have full understanding of the problem domain , have trouble communicating needs to system engineer, omit information that is believed to be obvious, specify requirements that conflict with the need of other customers/users , or specify requirements that are unstable or untestable.


Elicitation

• Problem of volatility: the requirements changes over the time.


Elaboration

• (focuses on developing a refined technical model of software functions, features, and constraints using the information obtained during inception and elicitation).

• The information is obtained from the customer inception and elicitation is expanded and refined during elaboration. This requirement engineering activity focus on developing a refined technical model of software functions features and constraints.


Elaboration

• Elaboration Is an analysis modeling action that is composed of number of modeling and refinement task. Elaboration is driven by the creation and refinement of user scenarios that describes how the end user will interact with the system.


Elaboration

• . Each user scenario is parsed to exact analysis classes business domain entries that are visible to end user. The attribute of each analysis classes are defined and services that are required for each classes are identified.

• The relationships and collaboration between classes are identified and variety of supplementary UML (unified modeling language) diagrams are produced.


Elaboration

• The end result of elaboration is an analysis model that defines the informational functional and behavioral domain of the problem.


Negotiation

• (requirements are categorized and organized into subsets, relations among requirements identified, requirements reviewed for correctness, requirements prioritized based on customer needs). It is not unusual for customer and user to ask for more than can be achieved, given limited business resources.


Negotiation

• . It is also relatively common for different customers or users to propose conflicting requirements, arguing that their version is “essential for our special needs”.

• The requirement engineer must reconcile these conflicts through a process of negotiation. Customer, users and other stakeholders are asked to rank requirements and then discuss conflicting requirements and then discuss conflicts in priority.


Negotiation

• Risk associated with each requirement are identified and analyzed. Rough estimates of development effort are made and used to assess the impact of each requirement on project cost and delivery time.

• Using an active approach , requirements are eliminated, combined , and/or modified so that each party achieves some measure of satisfaction


Specificaion

• written work products produced describing the function, performance, and development constraints for a computer based system.

• In the contest of computer based system and software the term specification means different things to different people.

• A specification can be a written document as set of graphical models a formal mathematical model a collection of usage scenarios a prototype or any combination of these.


Specificaion

• written work products produced describing the function, performance, and development constraints for a computer based system.

• In the contest of computer based system and software the term specification means different things to different people.

• A specification can be a written document as set of graphical models a formal mathematical model a collection of usage scenarios a prototype or any combination of these.


Specification

• However it is sometimes necessary to remain flexible when a specification is to be developed. For large systems a written document combining natural language description and graphical models may be the best approach.

• . However usage scenarios may be all that are required for smaller product or system that resides within very well understood technical environments.


Specification

• The specification is the final work product produced by the requirement engineer. It describes the function and performance of computer based system and the constraints that will govern its development.

•


Requirements validation

• formal technical reviews used to examine the specification work products to ensure requirement quality and that all work products conform to agreed upon standards for the process, project, and product.



The work product produced as a consequence of requirements engineering are assessed for quality during a validation step. Requirement validation examines the specification to ensure that all software requirements have been stated unambiguously, inconsistencies, omissions, errors have been detected and corrected and that work product confirms to the standard established for the process the project and the product.



The primary requirement validation mechanism is the formal technical.

The review team that validates requirements includes software engineers, customers, users and other stockholders who examine the specification looking for errors in content or interpretation areas where classification is required, missing information, and inconsistencies conflicting requirements.


Requirements management

Set of activities that help project team to identify, control, and track requirements and changes as project proceeds

Many of these activities are identical to those that make up the software configuration management (SCM) process .

Requirements are first identified, tagged with a unique identifier and classified by type (functional, data, behavioral, interface, or output)


Requirements management

Traceability tables (e.g., features, source, dependency, subsystem, interface) are developed and updated any time a requirement is modified)

Database systems are invaluable in helping software teams track requirement changes


Elements of Analysis model


Use-Case


Data flow diagram of level - 0


State Diagram


Class modelling


Activity Diagram

Documents

Requirement engineering & Requirement tasks/Management. 1Prepared By:Jay A.Dave