Requirements Collection

1. Requirements Collection By Dr. Gabriel

2. Requirements • A requirement is any function, constraint, or property that the system must provide, meet, or satisfy in order to fulfill its purpose. • Requirements may be separated into two broad categories, functional and non-functional • A functional requirement is a function that the system must perform. • Summarize Sales • Create Paychecks • Receive Shipment • A non-functional requirement is a characteristic or constraint that might limit our choice of technology when we implement one or more functional requirements. • Availability • Users must be able to access the system twenty fours hours per day. • Capacity/Performance • The system must be able to handle a peak load of thirty simultaneous users with no more than five second response time. • Time • The system must be implemented by December 31, XXXX.

3. Requirements • Requirements may be placed in two other categories that are useful to designers and builders. • Priority • Mandatory • The system will not be useful unless the requirement is met. • Desirable • The system will be more useful if the requirement is met. The requirement must be considered when alternative solutions are evaluated. • Optional • The system might be more useful if the requirement is met but the requirement should not be considered when alternative solutions are evaluated. • Stability • Stable • The requirement is not likely to change over the useful life of the system. • Volatile • It is very likely that the requirement will change over the useful life of the system.

4. Requirements • Requirements must be: • Correct • A requirement is correct if it describes something that a system must do or a constraint on the way it must be done. • Complete • A requirement is complete to the extent that all parts are present and each part is fully developed. The requirement set is complete if it contains all of the complete requirements. • Consistent • A requirement is consistent if it does not conflict with another requirement. • Nonambiguous • A requirement is non-ambiguous if there is only one interpretation of its meaning • Verifiable • A requirement is verifiable if and only if there is a finite cost effective process that a person or machine can use to check that the as built system meets the requirement. (Ambiguous and qualitative (subjective) requirements are not verifiable) • Traceable • An analysis requirement is traceable if it can be traced backward to a feasibility study, a white paper, meeting notes, or an interview.

5. Requirements Elicitation Techniques • Collaborative sessions • Interviewing • Ethnography • Questionnaires • Role playing • Documentation • Modeling • Prototyping

6. Requirements Elicitation Techniques • Collaborative sessions • Primarily useful for brainstorming and problem solving activities • It is a useful technique • Useful for identifying and negotiating conflicts that might exist between requirements.

7. Requirements Elicitation Techniques • Interviewing techniques • Are one of the simplest methods of requirements elicitation. • Most effective methods of requirements elicitation. • Interviews can either be structured around a specific set of questions, or open-ended with the intention of gathering as much useful information as possible. • It is often beneficial to combine both techniques in a single interview. • Interviews are often conducted in stages, so that responses from the first round can be used to generate a deeper set of more focused questions for the second round.

8. Requirements Elicitation Techniques • Ethnography • Involves observing the way users interact with an existing system. • This is particularly useful when users are unable to fully articulate their needs, or are too busy to attend other types of elicitation meetings.

9. Requirements Elicitation Techniques • Questionnaires • Can be useful if it is possible to formulate a very specific set of questions. • This usually is only possible when the problem is quite well defined up front. • Tend to be used more frequently in the form of market research surveys when developing a product for an external client, or to elicit a general response from a targeted group of stakeholders such as the users of an existing system.

10. Requirements Elicitation Techniques • Role-playing • Can be used to explore stakeholders needs when those stakeholders are unavailable. • This is particularly useful for example if you are developing a product that will be mass marketed and you don’t know who the actual users will be.

11. Requirements Elicitation Techniques • Documentation • Can provide significant insights into possible requirements. • Problem reports • Memos • User manuals from existing systems • Existing designs and specifications • Reports output from existing systems • Documentation from competitors’ products

12. Requirements Elicitation Techniques • Modeling • Can be used during the elicitation process primarily as a means of communicating back to the user the specific understanding of their needs. • Data flow diagrams (DFD), • State charts • Use cases and sequence diagrams • A model is useful during elicitation if it helps the elicitor to figure out which questions to ask, or if it surfaces hidden requirements. • In general, formal models are not that useful during the elicitation process primarily because they are typically not well understood by stakeholders.

13. Requirements Elicitation Techniques • Prototyping • is a useful technique for taking an early set of user requirements and rapidly building a ‘system’ that can be used to elicit additional requirements. • There are various types of prototypes. • Low fidelity models are built with pen and paper, index cards, and post it notes etc. • very little cost. • Higher fidelity prototypes, that utilize rapid development techniques to deliver a semi-functioning product to the user

14. Requirements • Requirements document states what the system will do. • It does not state how the system will do it. • Makes sure system does the right things • Makes sure system doesn’t do the wrong things • It’s a written document • The main purpose of a requirements document is to serve as an agreement between the developers and the users/customers on what the system will do. • The requirements document brings the following additional benefits: • the customers can see early on if their needs will be met • the developers can estimate the effort involved in creating the application • the development project leader has a basis for a project plan • the quality assurance people have a basis for testing the application

15. Requirements • Take iterative approach when writing requirements document • When you are collecting requirements it is very important to verify all of the facts by interviewing customers with differing points of view • users and management • users in different parts of the organization; etc. • Remember that different people in the same position and especially people in different positions have a different view of the business needs and business practices as far as your application is concerned.

16. Requirements • A requirements document should include requirements that meet all characteristics of requirements. In addition, a requirements document should be: • Understandable • A requirements document is understandable if it can be read and understood by those who were the source of the requirements and those who will use the requirements to create the system. • Modifiable • A requirements document is modifiable if its structure and style are such that changes to the requirements can be made easily, completely, and consistently. • Annotated • A requirements document is annotated if the relative priority and stability is appended to each requirement.

17. Requirements • Each requirements document consists of at least two parts • An overview • A description of the system’s functionality. • You must continue updating the document as the requirements evolve.

18. Questions ?