1. Some Sub-Activities within Requirements Engineering 1.Prototyping 2.Requirements Documentation 3.Requirements Validation 4.Requirements Measurements 5.Requirements Specification Technique and Choosing a Specification Method

2. (1) “Requirements” Prototyping Software Prototyping is used for a variety of reasons : 1.help elicit requirements 2.understand and drill down on the requirements 3.validate the requirements 4.demonstrate feasibility There are two major categories of “general” software prototyping: –Throw-away prototyping : exploratory and code is not kept as part of the final system –Evolutionary prototyping : forms the basis of the final system and code is kept as part of the final system

3. Prototyping: sub-process/procedure Set Objectives of Prototyping Get the Resources for Prototyping - elicit requirements - understand reqs. - demonstrate feas. - etc. - Evolutionary - Throwaway - customers/users - developers - analysts - consultants - hardware - software - etc. Construct the Prototype - schedule - cost Evaluate & Document result - document - evaluate - store results - store prototype

4. Prototyping Most “successful & popular” prototyping have been in the UI area : –Terminal/Screen Interface: screen looks : field positions, color, size, shapes, etc. navigation : logical flow; consistency, etc. usage-aids : help text, default values, default choices, etc. –Report /Document/Query Interface : looks : layout, titles and headings, fonts, diagrams, etc. usage : complete, consistency, etc. Feasibility Prototyping is the next most popular: –New Technology –Performance (response time, through-put, etc.)

5. Broader Prototyping Role Many times prototyping is extended into solution design: –feasibility of new technology –performance trade off –UI trade-off Prototyping, because it demonstrates a potential solution, allows the modification of requirements and active exchanges of ideas even after requirements has been signed off. One danger is customers and management mistaking prototypes with final solutions (especially with respect to wanting aggressive schedule!)

6. (2) Requirements Documentation Requirements collected and prototyped must be documented (text author advocates): –Requirements document (in user customer terms) Contains more customer goals and current environment information –Requirements specification (for developers) Contains more details about data, systems interface, functional logic But we usually do not have the luxury of 2 documents, but have one running document that contains all the information.

7. IEEE/ANSI 830-1993 Requirements document structure of IEEE/ANSI 830 Introduction –1.1 Purpose of requirements document –1.2 Scope of the product –1.3 Definitions, acronyms and abbreviations –1.4 References –1.5 Overview of the remainder of the document 2. General description –2.1 Product perspective –2.2 Product functions –2.3 User characteristics –2.4 General constraints –2.5 Assumptions and dependencies 3. Specific requirements –Covering detailed functional, non-functional and interface requirements. 4. Appendices 5. Index

8. IEEE Requirements Section 3 (cont.) 3.0 Specific Requirements –3.1 External Interface Requirements User Interface Hardware Interface Software Interface Communications Interface –3.2 Functional Requirements Function 1 Function 2. –3.3 Performance Requirements –3.4 Design Constraints –3.5 Quality Requirements –3.6 Other Requirements

9. (3) Requirements Validation & Verification Importance of Requirements Validation: 1.ensures that both the “customer/user” and the “developers” understand and agree on the goals, the objectives, and the characteristics ( both functional and non-functional) of the final system 2.any error found here is cheaper to fix than at later stages of the development process Some common validation techniques: –manual review of requirements definition and specification documents –prototyping Incidentally, requirements may also be negotiated ! Because in “real” world, most likely, there is only one requirements document --- we won’t talk about verification (“proper evolution”) here.

10. Requirements Review We are looking for (correctness, completeness, consistency, clarity, traceability and testability ) in: –characterization of functions –characterizations of the non-functions performance reliability, security, and accessibility –characterization of data –characterization of application, business, and logical flow –characterization of user interface –characterization of existing systems and related constraints

11. Requirements Review Other topics to understand and/or agree on: –customer/user domain or business environment –customer/user goals and objectives –customer/user expectations –customer/user priorities –customer/user background and training Will the system requirements that was just reviewed satisfy the above set of topics ?

12. (4) Some Measurements We construct metric and keep measurements so that we can perform and manage better in the future: (measurement is basic to “engineering”) –number of requirements by type ---- impacts : sizing of work and cost estimation estimating schedule –number of changes to requirements ----- indicates : stability of customer/user environment understanding of requirements by development completeness and consistency of initial requirements –number of changes to requirements ----- influences: number of defects in the final system customer satisfaction schedule and cost development personnel morale and confidence

13. Measurements Measurements in numerical form allows: –counting –comparison –compute –Estimate Be careful of your : –accuracy and reliability (consistency) of measurements –validity (applicability) of your measurements and conclusions

14. Possible Measurement Dilemma Suppose you took two samples of development organizations and asked them to review and measure all the requirements “readiness” (understand and have experience with) from 1 to 5 (with 1 been the best and 5 been worst) –Group 1 came out with an “average” of 2. –Group 2 came out with an “average” of 4. You may choose to go with the Group 1 that had a self measurement of readiness at 2. –But - - - what if the readiness for design and testing activities for the two groups came out reversed --- then what? (need to consider “complete information)

15. (5) Requirements Definition & Specification Techniques There are many techniques to choose from and more are invented continuously. Some characteristics to look for: –How difficult is it to use the technique? (the harder the more likely you will make error) –Is there a usage history? –Is there any tool implemented for this technique? –Is there any training material? –Is it broadly accepted ? (especially by customers/users) –Does it provide broad coverage of all types of requirements (functions, data, UI, business flow, non-functions, existing systems)