150 likes | 303 Views
Some Sub-Activities within Requirements Engineering. Prototyping Requirements Documentation Requirements Validation Requirements Measurements Requirements Specification Technique and Choosing a Specification Method. (1) “Requirements” Prototyping.
E N D
Some Sub-Activities within Requirements Engineering • Prototyping • Requirements Documentation • Requirements Validation • Requirements Measurements • Requirements Specification Technique and Choosing a Specification Method
(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
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
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.)
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!)
(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.
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
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
(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.
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
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 ?
(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
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
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)
(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)