I121 Systems analysis fundamentals

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