Some Sub-Activities within Requirements Engineering

1. Some Sub-Activities within Requirements Engineering • Prototyping • Requirements Documentation • Requirements Validation • Requirements Measurements • Requirements Specification Technique and Choosing a Specification Method

2. (1) “Requirements” Prototyping • Software Prototyping is used for a variety of reasons : • help elicit requirements • understand and drill down on the requirements • validate the requirements • demonstrate feasibility • There are two major categories of “general” software prototyping: • Throw-away prototyping: exploratory and code is notkeptas 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 Construct the Prototype Evaluate & Document result - elicit requirements - understand reqs. - demonstrate feas. - etc. - Evolutionary - Throwaway - customers/users - developers - analysts - consultants - hardware - software - etc. - document - evaluate - store results - store prototype - schedule - cost

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: • 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 • 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) ofyour 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)