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

(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

Prototyping: sub-process/procedure

Set Objectives of Prototyping

Get the Resourcesfor Prototyping

- elicit requirements- understand reqs.- demonstrate feas.- etc.- Evolutionary - Throwaway

- customers/users- developers- analysts- consultants- hardware- software- etc.

Construct thePrototype

- schedule- cost

Evaluate &Document result

- document - evaluate- store results- store prototype

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:

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.

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) of your 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)