Requirement Engineering Requirement Engineering Tasks Inception Elicitation Problems

Requirement Engineering

Requirement Engineering Tasks � Inception � Elicitation � Problems of scope � Problems of understanding � Problems of Volatility � Elaboration � Scenarios � Negotiation � Priority � Conflicts � Risks � Specification � Standard Template � Validation

How to perform? �Study current documents �Interview �Tasks Analysis �Scenario Analysis �Form Analysis

Context free question �Who is behind the request for this work? �Who will use the system? �What will be the economic benefit of a successful solution? �Is There another source for the solution that you need?

Breaking ice…. �What problems will this solution address? �Can you show me business environment where this system will be used? �Will special performance issue or constraints affect the way the solution is approached? �How would you categories a good output ?

�Are you the right person to answer these questions? �Are your answers official? �Are my questions relevant to problem you have? �Am I asking too many questions? �Can anyone else give me more information? �Should I be asking anything else?

Issues in Requirement gathering �Anomaly : ambiguity in requirement eg: high, low �Inconsistency : contradictions �Incompleteness

SRS document aspects: �Functional �Non-functional �Goals of implementation

Functional �Functionalities required by users from system. �Consider a system performing a set of function {fi}. �Functions can be considered as mathematical functions f : I -> O �Meaning that function transforms an element(Ii) in input domain (I) to a value (Oi) of output domain(O). �The functional requirement should clearly state each function which the system will support along with corresponding input and output.

Non functional �Characteristics of a system that cannot be expressed as functions �Addressing aspects like maintainability, �Portability, usability, maximum number of users, timing, throuhput, reliability, accuracy. �Eg: User interface of groundwork form should be usable by users who are not even high school degree holders.

Ice breaking continued… �question and answer meeting format is not an approach that has been overwhelmingly successful. � In fact, the Q&A session should be used for the first encounter only and then replaced by a meeting format that combines elements of problem solving, negotiation, and specification.

Facilitated Application Specification Techniques �A team-oriented approach to requirements gathering that is applied during early stages of analysis and specification. �This approach encourages the creation of a joint team of customers and developers who work together to identify the problem, propose elements of the solution, negotiate different approaches and specify a preliminary set of solution requirements.

basic guidelines : � A meeting is conducted at a neutral site and attended by both software engineers and customers. � Rules for preparation and participation are established. � An agenda is suggested that is formal enough to cover all important points but informal enough to encourage the free flow of ideas. � A "facilitator" (can be a customer, a developer, or an outsider) controls the meeting. � A "definition mechanism" (can be work sheets, flip charts, or wall stickers or an electronic bulletin board, chat room or virtual forum) is used. � The goal is to identify the problem, propose elements of the solution, negotiate different approaches, and specify a preliminary set of solution requirements in an atmosphere that is conducive to the accomplishment of the goal.

�Initial meetings between the developer and customer occur and basic questions and answers help to establish the scope of the problem and the overall perception of a solution. �Out of these initial meetings, the developer and customer write a one- or two-page "product request. “ �A meeting place, time, and date for FAST are selected and a facilitator is chosen. �Attendees from both the development and customer/user organizations are invited to attend. �The product request is distributed to all attendees before the meeting date.

�While reviewing the request in the days before the meeting, each FAST attendee is asked to make a list of objects that are part of the environment that surrounds the system, other objects that are to be produced by the system, and objects that are used by the system to perform its functions. �In addition, each attendee is asked to make another list of services (processes or functions) that manipulate or interact with the objects. �Finally, lists of constraints (e. g. , cost, size, business rules) and performance criteria (e. g. , speed, accuracy) are also developed. �The attendees are informed that the lists are not expected to be exhaustive but are expected to reflect each person’s perception of the system.

�After combined lists for all topic areas have been created. �The combined list is shortened, lengthened, or reworded to properly reflect the product/system to be developed. � The objective is to develop a consensus list in each topic area (objects, services, constraints, and performance). �The lists are then set aside for later action. �Once the consensus lists have been completed, the team is divided into smaller subteams; each works to develop mini -specifications for one or more entries on each of the lists. �Each mini-specification is an elaboration of the word or phrase contained on a list.

� Each subteam then presents each of its mini-specs to all FAST attendees for discussion. � Additions, deletions, and further elaboration are made. � In some cases, the development of mini-specs will uncover new objects, services, constraints, or performance requirements that will be added to the original lists. � During all discussions, the team may raise an issue that cannot be resolved during the meeting. � An issues list is maintained so that these ideas will be acted on later. � After the mini-specs are completed, each FAST attendee makes a list of validation criteria for the product/system and presents his or her list to the team. � A consensus list of validation criteria is then created. Finally, one or more participants (or outsiders) is assigned the task of writing the complete draft specification using all inputs from the FAST meeting.

Quality Function Deployment �Translates need of customer to technical requirement. �QFD identifies three types of requirements : �Normal requirements. If these requirements are present, the customer is satisfied. �Expected requirements. These requirements are implicit to the product or system and may be so fundamental that the customer does not explicitly state them. Their absence will be a cause for significant dissatisfaction. �Exciting requirements. These features go beyond the customer’s expectations and prove to be very satisfying when present.

� function deployment is used to determine the value of each function that is required for the system. � Information deployment identifies both the data objects and events that the system must consume and produce. These are tied to the functions. � Finally, task deployment examines the behavior of the system or product within the context of its environment. � Value analysis is conducted to determine the relative priority of requirements determined during each of the three deployments.

�QFD uses customer interviews and observation, surveys, and examination of historical data (e. g. , problem reports) as raw data for the requirements gathering activity. �These data are then translated into a table of requirements—called the customer voice table—that is reviewed with the customer. A variety of diagrams, matrices, and evaluation methods are then used to extract expected requirements and to attempt to derive exciting requirements.

Purpose of SRS �communication between the Customer, Analyst, system developers, maintainers, . . �firm foundation for the design phase �support system testing activities �Support project management and control �controlling the evolution of the system 21

IEEE requirements standard �Defines a generic structure for a requirements document that must be instantiated for each specific system. �Introduction. �General description. �Specific requirements. �Appendices. �Index. 22

Use-Cases �As requirements are gathered as part of informal meetings, FAST, or QFD, the software engineer (analyst) can create a set of scenarios. �To create a use-case, the analyst must first identify the different types of people (or devices) that use the system or product. �A typical user may play a number of different roles when using a system, whereas an actor represents a class of external entities (often, but not always, people) that play just one role. �Because requirements elicitation is an evolutionary activity, not all actors are identified during the first iteration. �It is possible to identify primary actors during the first iteration and secondary actors as more is learned about the system.

�Once actors have been identified, use-cases can be developed. �Jacobson suggests a number of questions that should be answered by the use-case: � • What main tasks or functions are performed by the actor? � • What system information will the actor acquire, produce, or change? � • Will the actor have to inform the system about changes in the external environment � • What information does the actor desire from the system? � • Does the actor wish to be informed about unexpected changes?

IEEE requirements standard 1. Introduction 1. 1 Purpose 1. 2 Scope 1. 3 Definitions, Acronyms and Abbreviations 1. 4 References 1. 5 Overview 26

2. General description 2. 1 Product perspective 2. 2 Product function summary 2. 3 User characteristics 2. 4 General constraints 2. 5 Assumptions and dependencies 3. Specific Requirements - Functional requirements -External interface requirements - Performance requirements - Design constraints - Attributes eg. security, availability, maintainability, transferability/conversion - Other requirements 27

�Appendices �Index 28