Requirements Acquisition ICS 121: Software Methods and Tools Topic 3: Requirements Acquisition Requirements Acquisition Requirements Overview Problem Analysis Mockups through Prototyping Spring 2000

Requirements Analysis and Specification ICS 121: Software Methods and Tools Topic 3: Requirements Acquisition Requirements Analysis and Specification Problem Definition informal statement of need for system Requirements Definition natural language statement of what system is to provide Requirements Specification notational and/or formal description of a software system Topic 3 Requirements Acquisition Spring 2000

Why write requirements? ICS 121: Software Methods and Tools Topic 3: Requirements Acquisition Why write requirements? Develop a contract between customer and developer Enables both sides to be clear about what is to be done Understand and specify requirements based on customer’s needs Not on what the developer thinks the customer needs Provide basis for definitive testing and verification System is acceptable if its passes the “acceptance” test Topic 3 Requirements Acquisition Spring 2000

Requirements in the Software Lifecycle What ? Topic 3 Requirements Acquisition

Goals for a requirements specification ICS 121: Software Methods and Tools Topic 3: Requirements Acquisition Goals for a requirements specification Identify the functional capabilities of the system Identify desired responses to undesired events Identify non-functional and environmental constraints to be satisfied “My users will submit input in the form of Microsoft Word documents” “It has to run on a ‘Pentium III under Windows 2000!” Avoid specifying “how” focus simply on “what” Serve as a guide to the development team Topic 3 Requirements Acquisition Spring 2000

Desirable Characteristics of a Requirements Specification ICS 121: Software Methods and Tools Topic 3: Requirements Acquisition Desirable Characteristics of a Requirements Specification Abstract one model, many realizations Complete to the extent required Consistent no contradictions Unambiguous concrete acceptance test Precise uniquely interpretable Testable Concise no extraneous details Feasible realistic constraints Even consistent level of detail Modifiable living document Reference Tool readable by all stakeholders No implementation bias Topic 3 Requirements Acquisition Spring 2000

ICS 121: Software Methods and Tools Topic 3: Requirements Acquisition Common Problems Incompleteness customer may be unavailable or inaccessible customer asks for too little customer doesn’t think of everything the world changes Note: sometimes incompleteness is okay (as long as its noted!) Inconsistency customer may be a group that disagrees different people may negotiate different parts Ambiguity customer may be a group where no one sees the whole picture difficult to spot ambiguity in large, complex applications Imprecision customer may be a group with a different vocabulary precision easiest in mature application areas (e.g. accounting) precision difficult in new disciplines Infeasibility customer asks for too much no conceivable algorithm unrealistic requests Unevenness different sources of information different people write different parts different parts of specification are more difficult than others Topic 3 Requirements Acquisition Spring 2000

Requirements Acquisition Caution Shortchanging requirements phase Emphasizing design Substituting test plans for requirements these are DEADLY to later development Topic 3 Requirements Acquisition

Requirements Analysis Process Domain understanding Requirements collection validation Prioritization Conflict resolution Classification definition and specification Process entry Topic 3 Requirements Acquisition

Products Refinement of customer needs Documentation of all requirements and constraints functional nonfunctional Lifecycle considerations Acceptance Test Plan Should not begin a project without a GOOD CONTRACT that completely describes customer expectations Topic 3 Requirements Acquisition

Non-Functional Requirements Efficiency Usability Reliability Portability Performance Space Delivery Implementation Standards Legislative R. Interoperability Ethical R. Privacy Safety requirements Process External Non-functional Topic 3 Requirements Acquisition

Method-based requirements analysis Most widely used approach to requirements analysis Depends on the application of some structured methods to understand the system Results are expressed in a set of system models Methods have different emphases: some are focused exclusively on requirements elicitation/analysis, others are very close to design Structured methods usually include: Process model (dataflow analysis, control scenario identification) System modeling notations (diagrammatic, form-based, linguistic) Rules applied to the system model Design guidelines Report templates Topic 3 Requirements Acquisition

ICS 121: Software Methods and Tools Topic 3: Requirements Acquisition Basic Methods Customer teaches; developer learns and organizes Developer applies discipline to process and helps discover ambiguity, inconsistency, and incompleteness Interviews, investigations, questionnaires Informal description Glossaries to aid communication Mockups through prototyping and scenarios Semi-formal description Hierarchical decomposition System modeling Dataflow diagrams, E-R Diagrams, Finite state machines, Petri nets, etc. Topic 3 Requirements Acquisition Spring 2000

Informal Requirements Specification ICS 121: Software Methods and Tools Topic 3: Requirements Acquisition Informal Requirements Specification Structured Natural Language Extended, more detailed form of the client’s requirements definition Advantage Uses expressiveness and understandability of natural language Problems Inherent ambiguity of natural language Requirements are not partitioned effectively by the language itself (difficult to find related requirements) Topic 3 Requirements Acquisition Spring 2000

Typical contents of an informal (textual) Requirements Specification ICS 121: Software Methods and Tools Topic 3: Requirements Acquisition Typical contents of an informal (textual) Requirements Specification Description restatement of problem definition Functionality “what” the system does Data “what” the system processes Environment “where” the system operates Robustness “what” is expected of the system in unusual circumstances Security “who” has access to “what” Safety can this system harm anyone Performance “what” constraints are placed on the system’s performance Resources “what” information/other systems is/are available to help the system accomplish its job Topic 3 Requirements Acquisition Spring 2000

ICS 121: Software Methods and Tools Topic 3: Requirements Acquisition Mockups First step: build mockup for client/user experimentation Rapid prototypes or scenarios as a means to understanding and requirements acquisition serves as a communication device with the user “I don’t know what I want, but I don’t want THAT!” facilitates technical exploration “Is this possible?” refines the problem definition “I want that …” aids the development and assessment of specifications “That looks good …” also serves to build confidence that the developers are planning something that meets client’s needs Next: follow another lifecycle model Topic 3 Requirements Acquisition Spring 2000

Rapid Prototyping and Scenarios Address problems of requirements acquisition completeness of user needs adequacy of user services usability of user interface incomplete and/or inconsistent requirements specification system feasibility analysis of alternative design decisions Help in understanding user needs Is the proposed service/system adequate? Is the user-interface usable? Are the requirements complete? Which alternative should we take? e.g. present the user with multiple “throw-away” prototypes Means of EARLY Requirements Analysis Topic 3 Requirements Acquisition

Rapid Prototyping Lifecycle ICS 121: Software Methods and Tools Topic 3: Requirements Acquisition Rapid Prototyping Lifecycle Rapid Prototype Verify Retirement Operations Test Implementation Design Req. Change Scenarios can be used as mockups in the same way Topic 3 Requirements Acquisition Spring 2000

ICS 121: Software Methods and Tools Topic 3: Requirements Acquisition “Rapid” is key! The prototype must be constructed quickly! Thus, inconsequential problems are minor as long as main aspect of the prototype functions correctly A prototype should be designed to be rapidly changed This supports iteration in the process If the user doesn’t like it, incorporate the feedback and try again! To support these requirements, fourth-generation languages or interpreted languages are often used to generate prototypes Topic 3 Requirements Acquisition Spring 2000

Rapid Prototyping Tools Executable specification languages Animation of a formal system specification to provide a system prototype Problems: GUI cannot be prototyped Executable system usually slow and inefficient Executable specifications only test functional requirements Very high level languages Programming languages which include powerful data management facilities (simplifies program/prototype development) Examples: Lisp, Prolog, Smalltalk, APL Fourth-generation languages Powerful languages, especially in the business system domain Examples: Database Query Languages (including report generator, etc.) Scenarios and Human-Computer Interaction Topic 3 Requirements Acquisition

Exploratory Programming Lifecycle Develop outline specification because full requirements are not known, build mockup system, expose to user review & enhance until performance is adequate B u i l d S o f t w a r e y s m O p n D v M c I P U A similar but BAD approach! Topic 3 Requirements Acquisition

Rapid Prototypes as specifications... ICS 121: Software Methods and Tools Topic 3: Requirements Acquisition Rapid Prototypes as specifications... Instead of discarding the prototype, use it to serve as the specification Saves time having to write a specification document! Generally considered a bad idea... because a rapid prototype can’t serve as a legal contract a rapid prototype does not make for good documentation It can’t serve as a reference tool for maintenance, for example. Prototypes should be used to elicit requirements and then discarded, next comes design... Topic 3 Requirements Acquisition Spring 2000

Rapid Prototypes as the finished product! ICS 121: Software Methods and Tools Topic 3: Requirements Acquisition Rapid Prototypes as the finished product! Also considered a bad idea... Same problems as previous... Plus Its too easy to slip into the build-and-fix lifecycle! Topic 3 Requirements Acquisition Spring 2000

ICS 121: Software Methods and Tools Topic 3: Requirements Acquisition Training the client... Customer and/or users may confuse a prototype with the operational system “Why do we have to wait so long for the system, didn’t you have it working three months ago?” Customer may request more features than originally intended “Hey that’s great! Can you add this...and this?” Thus...client should be informed as to the purpose of the prototype and be aware of the position of requirements in the life-cycle... Topic 3 Requirements Acquisition Spring 2000