1 / 34

I121 Systems analysis fundamentals

Week 3 – Requirements Elicitation Techniques. I121 Systems analysis fundamentals. Objectives Today. Definition of ‘requirements’ Types of Requirements . Definition of Requirements. A requirement is: A condition or capability needed by a user to solve a problem or achieve an objective

tamira
Download Presentation

I121 Systems analysis fundamentals

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. Week 3 – Requirements Elicitation Techniques I121 Systems analysis fundamentals

  2. Objectives Today • Definition of ‘requirements’ • Types of Requirements

  3. Definition of Requirements • A requirement is: • A condition or capability needed by a user to solve a problem or achieve an objective • A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents • A documented representation of these conditions or capabilities

  4. Types of Requirements • Business Requirements: • high-level statements of the goals, objectives, or needs of the organisation • describe why a project was initiated, the things that the project will achieve, and how success will be measured

  5. Types of Requirements • User Requirements: • statements of the needs of a particular user or group of user. • describe the needs that a given user has and how they will interact with the system • user requirements are gathered using a variety of techniques (more to follow)

  6. Types of Requirements • Functional Requirements • describe the behaviour and information that the solution will manage • describe capabilities the system will be able to perform in terms of behaviours and operations – a specific system action and response

  7. Types of Requirements • Quality of Service • capture conditions that do not directly relate to the behaviour or functionality of the solution, but rather describe environmental conditions under which the solution must remain effective or qualities that the system must have (also know as non-functional requirements)

  8. Assumptions and Constraints • As part of requirements definition we must identify those things the will limit or impact the design of the solution • e.g. customer has an existing database that must be used by the new system

  9. Benefits of effective Requirements practices • A clear understanding of the needs of the users, customers, and stakeholders • A collaborative relationship between the users, customers, stakeholders, and the technical team • A system architecture that supports the users, customers, and stakeholders current and planned needs

  10. Requirements Elicitation • Eliciting requirements is a key task of Systems Analysis • The requirements are the foundation for the solution to the business needs - so it is essential that they are complete, clear, correct, and consistent • To ‘elicit’ is to: • draw forth or bring out

  11. Stakeholder Identification • Stakeholders must be identified first, so we know who to try and get requirements from • Stakeholders are all of the people who have an interest in the successful implementation of the system

  12. Stakeholders • Stakeholders are generally categorised into three types: • The users of the system • The client (those who pay for and own the system) • Technical staff – the people who ensure that the system operates

  13. Requirements Elicitation • We need to determine business requirements, assumptions, current reality, and constraints by communicating with stakeholders using a variety of techniques

  14. Assumptions • During analysis the analyst may need to make an assumption about the system requirements • Assumption: the belief that something is true without having any proof • Any assumptions made when drawing analysis models are written down and checked for accuracy with the users of the system

  15. Exercise • For 2 minutes, talk to the person next to you about: • What techniques can we use to try and get the requirements of the new system from the stakeholders?

  16. Requirements Elicitation Techniques

  17. Brainstorming • Prepare • Define the area of interest • Establish criteria for evaluating and rating ideas • Brainstorm • Visibly record all ideas, try to build on the ideas of others or share ‘exaggerated’ ideas – the goal is to be creative • Wrap-up • When time is up, evaluate and discuss the ideas based on agreed criteria. Rate them, distribute final list of ideas

  18. Document Analysis • Document Analysis is used to gather details of the ‘As Is’ environment such as existing business rules, entities, and attributes that need to be included in the new system or updated in the current system • Useful technique also when ‘subject matter’ experts for the existing systems are no longer with the organisation

  19. Document Analysis • Prepare • evaluate which system and business documentation are relevant and appropriate to be studied • Analyse the documents • Examine the material to identify the relevant business details • Document business details as well as questions for follow-up • Wrap-up • Review and confirm with subject matter experts. Obtain answers to follow-up questions

  20. Focus Group • A focus group is composed of pertinent individuals who come prepared to discuss and comment on a topic • This is an opportunity for individuals to share their own perspectives and discuss them in a group setting • Qualitative: session results are analysed and reported as themes and perspectives, rather than numerical findings

  21. Focus Group • Prepare • recruit participants (typically 6 – 12) • assign moderator and recorder • create discussion guide (5-6 open questions) • Run session • Moderator guides group discussion • typically 1-2 hours in length • Produce Report • Moderator analyses and documents participants’ agreements and disagreements and synthesises them into themes

  22. Interview • Prepare • define interview goals • identify potential interviewees • design the interview (structured / unstructured) • contact interviewees and arrange time • Conduct • open by introducing yourself and explaining purpose • ask questions, practice active listening

  23. Interview • close the interview by asking if there is anything else they would like to add • summarise the session and thank the interviewee • Post interview follow-up • organise the information elicited and send notes to the interviewee for review • correct any errors or misinterpretations

  24. Survey • A survey administers a set of written questions to the users • Responses are analysed and distributed to interested parties • Questions in a survey can be open-ended or closed questions

  25. Open and Closed Questions • Closed: simple one answer questions, or questions where the respondent is asked to select from a list of responses • Open-Ended: respondent is free to answer the questions as they wish. Responses may provide more detail, but are more difficult to quantify and summarise

  26. Survey • Prepare • requires detailed preparation to ensure the needed information is obtained • define the purpose of the survey and the target survey group • select the sample group • determine the desired response level (incentives can increase the response rate to 80%) • write the survey questions • test the survey

  27. Survey • Distribute the survey • Communicate the results • collate the responses • analyse and summarise the results • report findings

  28. Observation • Two approaches: • Passive / invisible – analyst observes the subject matter expert working through the business routine and writes notes about what the person does. Analyst stays out of the way and only asks questions when the entire process is complete • Active / visible - analyst observes the subject matter expert working through the business routine and may interrupt and ask questions at any time. Analyst may actually participate in the process to improve their understanding

  29. Observation • Prepare • Determine which users you will observe • prepare questions to ask during or after shadowing • Observe • introduce yourself to the person being observed • take notes – if using active observation ask probing questions about why things are being done • Wrap-up • provide a summary of notes for review and verification

  30. Requirements workshops • Also called JAD workshop (Joint Application Design) • Involve key stakeholders and subject matter experts and are used to generate ideas for new features or products, to reach consensus on a topic, or to review requirements • usually 1 – 2 days

  31. Requirements Workshops • Prepare • identify participants • create workshop agenda • schedule the session and arrange room and equipment • send materials in advance to prepare the attendees and make the session more productive

  32. Requirements Workshops • Conduct • run the workshop and elicit, analyse and document requirements • obtain consensus on conflicting views • Wrap-up • Follow up on any open action items that were recorded at the workshop • Complete the documentation and distribute it to the attendees and the sponsor

  33. Reverse Engineering • Reverse engineering is a process of analysing a system / product to identify underlying business processes, data and rules • Black Box Reverse Engineering: The system / product is studied without examining its internal structure • White Box Reverse Engineering: The inner workings of the system / product are studied

  34. Practical Session this week • Review of last weeks exercises • Stakeholder analysis • Elicitation Exercise

More Related