1 / 18

Requirements Gathering : Determining the scope of the system

Requirements Gathering : Determining the scope of the system. 1. Elicitiation – fact finding 2. Specification 3. Validation. Problem-solving model. Sense. Listen. Examine. Gather data. Question. Problem (Re) Definition. Finding ideas. Finding and evaluating Solutions.

valterra-watson
Télécharger la présentation

Requirements Gathering : Determining the scope of the system

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. 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

  14. Decision Tables

  15. 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

  16. 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

  17. 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?

More Related