Requirements Gathering : Determining the scope of the system

1. Requirements Gathering : Determining the scope of the system 1. Elicitiation – fact finding 2. Specification 3. Validation

2. Problem-solving model • Sense Listen Examine Gather data Question • Problem (Re) Definition Finding ideas Finding and evaluating Solutions Implement and evaluate solution

3. Defining the scope….. Functional requirements Non- functional requirements • Hardware, software constraints • Security • Performance e.g. Response time • Integration • reliability • Quality - ISO standards can provide checklists here.

4. Requirements Elicitation Techniques • Interviews • Questionnaires • Existing Documentation – forms, reports etc. • Observation • Structured meetings e.g. participatory design

5. Requirements Elicitation:aim • To find out as much as possible about the business requirements for the system.

6. Interviewing Identify initial stakeholders, actors in system and find out their requirements. • Identify who the stakeholders are. • Plan • list objectives, subjects, topics, questions, strategy • organise time and location • list what documents should be brought to the interview • Conduct Interviews – listen, validate, record • What types of information can you find?

7. Interviews What are the users trying to accomplish and why? • Plan and prepare well • Have clear objectives • Work out structure and questions in advance

8. Observation Watching people doing their jobs shows: • exception situations, interruptions • problems • time taken to complete tasks • might give you an idea of what problems the new system could solve.

9. Questionnaires • Good for finding out information from large groups of people or geographically disparate groups.

10. Documenting Requirements • Filter out relevant issues and record them in an appropriate form e.g. • Context Diagram • DFDs • E-R diagrams • Use-Case diagrams • Textual descriptions • Desirable Characteristics of specification • Correctness • Consistency • Completeness • Understandability

11. Context Diagram • Shows inputs and outputs to system and the sources/recipients of these lecturer student Student registration system Class list Registration details Module code Student ID Course details Course designer

12. Entity- Relationship diagram • Shows key entities and their relationships course student module

13. Data Flow Diagram • Shows business processes, information flows and data stores 3.0 Generate new student number Student number 2.0 process student details Yes/no Student details Course code, Student details 1.0 input student details 4.0 Check course eligibility Course code Student record Student details student Course record Student file Student record Course file Student card 5.0 Print student card

15. Decision Tables

16. Use Case Diagrams • Business requirements – essential use cases Book spa Hotel self service subsystem <<includes>> Check valid room number Order food/ drink <<includes>> <<includes>> Request alarm call Guest

17. Each Use Case • Describes a system function from a user’s perspective • Details business events and users interaction with the system during that event • Represents a system activity, a well-defined part of the system’s functionality • Has a goal • Supported by behaviour specifications (templates) • Has a more detailed description, possibly specifying a number of scenarios or alternate courses of action

18. Use cases are initially defined at a high level and successively refined as the analysis and software development process unfolds. • Essential use case – key business requirements • Real Use Case – more detail about what actually happens What are the users trying to accomplish and why?