Requirements Elicitation , Analysis & Negotiation

Requirements Elicitation, Analysis & Negotiation Requirements Elicitation Requirements Analysis & Negotiation Set of Documented Requirements

Requirements Elicitation • Requirements Elicitation: Activities involved in discoveringand in bringing outthe users/customers needs and wants - - - for example: • Find out and understand the problemsto be solved • Find out and understand the goals and objectives(in theform of systemsservices needed) • Find out the required “performance” of the solution • Find out constraints, such as hardware and other, on the solution It is not as simple as “let’s ask the users what they want.” Why ? Because -------?

Difficulties of Requirements Elicitation • User/Customer: • Don’t always know all the requirements; may only know their own respective areas • May not know the grand, organizational needs and objectives • May not know the “politics” at play • May give conflicting requirements • May prioritize differently among themselves • May intermix needs with wants • May not have time or forget to give the complete picture • etc. • Requirements Analyst: • May not be a good listener • May not understand the domain (the domain specific language) and misinterpret the user/customer meaning • May not be trained, prepared or organized for elicitation • May not have enough time • etc.

4-Dimensions of Requirements Elicitation Acquire the Application and Industry Domain Knowledge - basic - current trends Acquire the user/customer problem knowledge - general problems - specific problems Acquire the user/customers constraints and needs info - for all stakeholders -users -managers - IT/admin etc. Acquire the user/customer business context information - organizational goals - inhibitors You need to know MORE than just the user/customer stated needs/wants ---

Requirements Elicitation & Stakeholders • Requirements can not be understood well unless the requirements analyst is familiar with that industry and has domain specific knowledge --- know all the stakeholders • All levels of stakeholders must be interviewed in order to understand the complete needs and constraints ( including organizational, political and business needs); some points to watch: • Not everyone has (or given enough) time to meet • People will present their biased views & some has hiddenagenda • Not everyone has good communications skill and can not clearly articulate their needs • Requirements also change because stakeholders change and because the world change • There is no oneeffective& structured method for requirements elicitation, but: • - experience and knowledge in domain • - some training • - maze brightness • may help What is this?

Elicitation, Analysis & Negotiation Interleavedand may Iterate several rounds requirements document Requirements Elicitation Requirements Negotiation draft statements of requirements Requirements Analysis list of problems with requirements When does the spiral of activities stop? When should it stop? ------- is this purely gated by schedule?

A “Broader” View of Elicitation Process 1. Business Goals 2. Major Problems to be Solved 3. Systems Constraints 1. Organiz. Structure 2. Applic. Domain 3. Existing Systems 1. Identif. Stakeholders 2. Prioritize Specific Goals 3. Filtering Unnecessary knowledge 1. gather Stakeholder Reqs 2. gather Domain Reqs. 3. gather Organiz. Reqs. (D) Collect Stakeholders Needs/Wants (A) Understand Overall Objectives (B) Acquire “Background” Information (C) Organize Collected Information “elicitation” Requirements “Draft” Document

A Reality Check ----- • How much of information can you realistically gather in a software project ? • That depends! • Time/schedule • Cost • People (domain and industry knowledge) • etc. • For your class project, how much do you plan to gather? • Purpose of the class exercise is to ---- have you just get a “feel” for the effort required ---- (put this part of the experience in your write-up)

Requirements Analysis & Negotiation Process Flow Req. Draft Analysis Consistency & Completeness checking Necessity checking Feasibility checking Unnecessary requirements Conflicting & Incomplete requirements Infeasible requirements Requirements Clarification/ Discussion Requirements Prioritization Requirements Compromise/ Agreement Negotiation

Requirements “Elicitation” - details • What is Elicitation – some details: • Gathering: • Interview Users, Management, and other Stakeholders • Interview Systems Operations (if any) • Read/Understand Business Workflows • Discuss and “Modify” Business Process • Rapid (throw-away) Prototyping (especially for UI and workflow) - - more later • Documenting/Recording: • Business: Goals/Constraints, Processes, Workflows • User profile, usage, and problems • Functional Scope and Needs • Structuring the gathered information: • Partitioning: grouping of specifics gathered into “broadly” related aggregates • Abstraction: generalization from the specifics gathered • Projection: grouping of specifics by different perspectives (performed during or after elicitation) (Gets into analysis)

Elicitation Techniques (requires good listening skills, conversational skills “Like” People • Interviews may be: - Closed : predefined questions and seek answers • Open: broad question that lead to open-ended answers • Developing Scenarios through a) studying the various documents, b) observing the business flow and operations, and c) interviewing the users. (A scenario is a set of interactions to achieve some result) • Observation and analysis of business and operations may be done through lengthy ethnographic analysis (or more practically by hiring an experienced domain knowledgeable requirements analyst and shorten the observation process) • Soft System Method is a help-aid to thinking about a system in a broader human/organizational context – such as user centered design or broader analysis/modeling of of business needs, people needs, etc. (sort of like ethnographic or business-cultural study) • Reuse of common requirements: (many are same across businesses) • Security • Recoverability • Look and feel usability • etc.

What do we talk about at Interviews? 1. Business Opportunity • Opportunity and Needs: what is the driving concern, be it people or business or systems • Justification : tell us how this investment is justified • Scope : tell us the boundaries and who/what are included • Constraints: tell us the schedule, budget, resource, etc. limits (both soft and hard limits) 2. Functional Objectives, Goals, and Needs • Objectives: tell us your goals such as improve accuracy, speed, etc. • e.g. reduce customer order response time: tell us what would be your goal and what is it today ? (performance need) • e.g. analyze customer buying habit: tell us how do you do it today, any problems in doing this, and how you would like it to be ? (functional need) 3. Users and usage/functionalities • User profile and needs : tell us your job title, your functions and how do you perform your functions today, and any problem/suggestion for improvement.

6-Dimensions of Requirements Business Workflow Individual Functionality Data and Data formats Requirements Existing & Systems Interfaces Other Constraints: Performance, Reliability, etc. User Interfaces Use these 6 categories as a prompter or as a checklist for “completeness” of requirements elicitation

Example of Functional Description “Form”for Eliciting Requirements • Functional/Information Requirement: • req # 27 - Order Entry for Standard Orders • Input Information: • Part number • Quantity • Customer Data • Shipping data • Processing : • Take customer order • Take customer data • Take shipping/billing data • Inventory query by part number • Output Information: • Response to part number query - - quantity on hand, selling price, any bulk discount, • Response to Order with Customer name, date, ship to, bill to addresses- - - for each order line with part-number, price, quantity, total price, and total invoice amount of all order lines Req. Input Process Output

Soft System Methods – ‘Analysis & Negotiation’ • For more general requirements such as business, objectives, and goals, one may use a more general approach as a guideline: (also used by some sales people) • Problem Situation Assessment: finding out about problem areas in an organization • Problem Situation Descriptions: use simple (pictorial and phrases) to clearly depict the problem --- without accusation • Abstract System Definition: provide an abstraction (Definitions) of the existing condition from different view points or perspectives. • Conceptual System Modeling: provide a system model of for each of the view-point based definitions • Model/Real World Comparison: Compare the model against the current real world situation (perhaps using scenarios and storyboarding ---- in later charts) • Change identification: identifying potential areas of change based on the model/real world comparison • Recommendations for Actions Make Recom. Understanding problem areas Model the situation Compare with “real” world Identify Changes Sales?

Elicitation & Analysis (Scenarios) • Read, Observe & Understand Application Domain, Business Workflow and Processes ( Alternative Sources for Developing Scenarios: ) • Observe & Study Current Processes & Process Documents • Study Current Forms • Study Current Reports • Observe & Study Current/Existing Information System and how it is Used • Formal System (by usage and function) • Inputs • Process • Outputs • Informal System • Communications : mail, file transfer, fax, phone,etc. • Query : formal and adhoc • Storage : screen copies The more experienced you are the easier is to perform these; otherwise it may take a lengthy ethnographic approach.

Elicitation & Analysis (Prototyping) • A prototype is a mock-up or a model of a system - it may be : • Throw-away: intended to help i) elicit and document requirements or ii) show feasibility of a particularly difficult area; it is discarded afterwards 2. Evolutionary: intended for delivery of a first version of the system to the customer and be used as a basis for further development of additional versions; it is kept, modified and incrementally improved. - Our interest is in the throw-awaytype, used mainly for requirements elicitation. - User interface (looks & navigation) requirements are great candidates for this

Prototyping • There are several types: • Paper and manual (low fidelity) • Partial automation & manual simulation (low fidelity) • Automated & executable (high fidelity) • It is not free: • Training for prototype development (or hire experienced ones) • Development of prototype (skilled resources & management) • Extending Requirements phase (schedule) • May mislead customers in its “easiness” • Automated tools for prototyping: • Simple tools such as power point, story board, etc. • Visual languages such as visual basic, objectworks, etc. • Web based PHP, DHTML, Javascript, etc.

Prototype User Scenarios (for analysis & negotiation): via Storyboarding • A storyboard is a method that • (1) shows what the elicitor thinks the user may need, • (2)shows what the elicited requirements look like when organized in a certain fashion, and • (3) it is used to further elicit a user reaction of “yes/no/yes-but/no-but” or “it doesn’t seem to do” • prototype beats asking the user/customer to just “again, tell me more - - -” from following up on earlier elicitation sessions. • Anything put in front of the user requires the “users to react,” • rather than having the user to recall and explain from scratch

Modes of Storyboarding • Passive: tells a story to the user by using pictures, screens shots, power point slides, and sample outputs. • Guided manually by a person who “talks” through the presented media. • Active: provides a more animated and automated way of presenting the story • Guided by an automated mechanism like a movie show that takes the user through different scenarios • Interactive: lets the user “experience” the system in a more realistic manner • A prototype system that allows/requires the user to interact with the system The techniques and tools for storyboarding has been an integral part of the creative process in the cartoon and movie industry

Practical Tips about Storyboarding • Don’t invest too much in a storyboard or make it too good a prototype • Users may be intimidated and won’t want you to change because it looks like the “real system” • Make the storyboard easy to modify • It is used to elicit users’ opinion • Whenever possible, make it interactive • Users’ experience with the system will generate much more reaction/requirements • Note : * * the more successful the more changes will be needed * *

3 Essential Elements of Storyboarding • Who: defines the users of the system, other systems, and/or devices: • Usually described via input screens, data entry windows, output forms or reports, etc. • What: defines the behavior of the users as they interact with the system and the behavior of thesystem as it interacts with the users • Described via navigation flow of the interactions • How: describes the states of the user or the system or both during the interactions • Describes further the characteristics of the behavior of the user and the systems (e.g. novice versus experienced)

Further Requirements Analysis • Find problems in the Requirements “Draft” Document: • Are all the stated requirements necessary and related to the stated goals and problems? • Are all the requirements consistent with each other, and are the requirements complete? • Are the requirements resolvable (do-able) within the constraints of time, budget, etc.? 1. The result of requirements analysis is an intermediate document that delineates: unnecessary requirements, contradicting requirements, and/or unfeasible requirements , and unclear requirements. 2. This information is used for requirements negotiation and possibly for re-iterating through the elicitation steps.

Requirements Analysis • Requirements analysis at this point is dealing with an early draft document and is time consuming • Some general techniques for analysis are: • Checklist: A list of “reminders” to think about and used to assess each stated requirement 2. Interaction Matrix: A 2-dimensional matrix of requirements where each requirement is compared with all other requirements and assessed for conflict, overlap or independence

Sample Checklist • Premature Design: • Does the requirement include pre-mature design • Combined Requirements: • Is this a compound requirement that can be broken down? • Unnecessary Requirement: • Is this a need or a nice-to-have requirement? • Use of or lead to “non-standard” system: • Does this requirement leads to non-standard hardware or software • Conformance with business goals and objectives • Does this requirement violate any objective or goal? • Ambiguity: • Can there be multiple interpretations, or is anything not clear? • Feasibility/Realism: • Can the requirement be solved within the constraints of technology, schedule, cost, etc. • Testable: • Can this requirement be tested and be validated after implementation?

Interaction Matrix • A technique, using a n-requirements by n-requirements matrix, to compare requirements for conflict and overlap R1 R2 R3 R4 R5 0 0 1 0 0 R1 - fill in 1 for conflict - fill in 100 for overlap - fill in 0 otherwise R2 0 0 100 0 0 R3 1 100 0 1 0 R4 0 0 1 0 0 0 0 0 0 0 R5 This matrix is symmetrical across the diagonal; so only a partial matrix is needed?

Documentation • Information obtained during Elicitation and later Negotiated • Recordings with prepared “form” for interviews and discussions as both prompter and recording media & (user reactions from prototypes) • Design the form ahead of time for both elicitation and documentation ( this takes time and forethought) • General business opportunities • Functional, performance, and information descriptions • Users and usage • Include copies of existing workflow and process documents • Marking areas that are ambiguous • Marking areas that touches directly the scope of this requirement • Automating the Documentation • Use an automated requirements gathering system to record and control the information (if applicable and affordable) • Initial usage set up • Put in “Control Process” • Enforce the usage of the system (** especially for down stream processes) • Produce a Requirements “Draft” Document (for negotiation, then a more complete one for formal review later)

IEEE STD-1998 (pp 15-16 of your text) • Section 5 :Parts of an SRS • Introduction • Overall Description • Specific Requirements • Supporting Info • Also look at the Appendix A for different templates for section 3 – Specific Requirements (passed out in class) Get on the web and search for the IEEE Requirements Std -1998 to get a complete copy of the document.

Requirements Negotiation • Resolve the problems found during requirements analysis: • Discuss with the stakeholders on the problems discovered in the draft requirements • Unnecessary and unrelated (out of scope) • Inconsistent, incomplete, conflicting, unclear • “infeasible” within constraints of budget, time, etc. • Broad prioritization of requirements into groups • The negotiation process is often a compromise governed by organizational, political, personality, and business considerations • Negotiations are usually performed in meetings and headed by someone who has no axe to grind --- also have the authority to make/force decisions If you used a prototype, then you may want to use it again for negotiation After Negotiation, a) set a baseline for the agreed-upon requirements, b) formally review the document, c) put a change process in place.

Another Example of Requirements DocumentUsing the 6 Categories of Requirements • Introduction: General discussion & the Business Flow (pictorial if needed and/or include your “prototype”) • User Interface: • General standards & policy • User profile • User interface flow and navigation • Individual Function and Features: • Each Functionality • UI involved for that functionality • Data and data formats involved for that functionality • Existing Systems and Systems Interfaces: • Data and Data interface • Functionality interface • Other Constraints: • Performance • Reliability • Recoverability & etc. Where’s the 6th category? - the data, data formats & data interface

Requirements Elicitation , Analysis & Negotiation