1 / 15

Some Sub-Activities within Requirements Engineering

Some Sub-Activities within Requirements Engineering. Prototyping Requirements Documentation Requirements Validation Requirements Measurements Requirements Specification Technique and Choosing a Specification Method. (1) “Requirements” Prototyping.

gavan
Download Presentation

Some Sub-Activities within Requirements Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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)

More Related