1 / 32

IMAT1906 Systems Development

IMAT1906 Systems Development. Lecture week 7: systems analysis (2) : requirements. Today’s Agenda. Requirements gathering Fact finding for detailed understanding Requirements specification Test strategy Assignment 2 scenario and tasks. Purpose.

feng
Download Presentation

IMAT1906 Systems Development

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. IMAT1906 Systems Development Lecture week 7: systems analysis (2) : requirements

  2. Today’s Agenda • Requirements gathering • Fact finding for detailed understanding • Requirements specification • Test strategy • Assignment 2 scenario and tasks IMAT 1906 Lecture Week 7 (c) De Montfort University 2010-11

  3. Purpose • Having done the feasibility study and gained approval to proceed with systems development.... • ...what’s next? • Now we have to discover what are the requirements for the new system IMAT 1906 Lecture Week 7 (c) De Montfort University 2010-11

  4. Factfinding for requirements 4 IMAT 1906 Lecture Week 7 (c) De Montfort University 2010-11 • During the feasibility study we carry out fact finding for overall understanding of a business problem • Fact-finding for requirements needs to be more detailed • Allows a more detailed understanding of situation • Leads to more detailed specification of requirements • Two things to investigate • what the system is to do or achieve (functionality) • what data is needed to support the functionality (data)

  5. What is a fact? 5 IMAT 1906 Lecture Week 7 (c) De Montfort University 2010-11 • First a definition: • facts are verified pieces of data (Skidmore & Eva, p 74) • For example, a user might tell you they process 100 forms a day, but when you look for the evidence it turns out they actually process 25 in one day – it just feels like 100 • If you use unverified information as if it was fact, the system you develop may not really meet the requirements

  6. Requirements gathering • Several kinds of requirement • Functional requirements • Data requirements • Non-functional requirements IMAT 1906 Lecture Week 7 (c) De Montfort University 2010-11

  7. Functional requirements • What is the system going to help the users to do • What functions do the users need – this is the functionality for the new system • What processes underpin the functions • Sometimes it helps to look at the business process outside the system • This can indicate what the user will expect the system to do or provide to help them do their work • What reporting requirements are there • Operational reports – for example details of a helpdesk call • Management reports – for example weekly sales totals • Ad hoc reporting – for example summary of a marketing campaign IMAT 1906 Lecture Week 7 (c) De Montfort University 2010-11

  8. Documenting functional requirements • Can document in many ways: • Requirement descriptions or catalogues – there are many terms for this, which is sometimes confusing but in any one organisation they will usually use the same term • Use case models – use case diagrams with supporting use case descriptions • Data flow diagrams • Structured English – step-by-step logic of process • Decision tables – set out rules and actions, for example for loan applications • Won’t always need all of these techniques • Choose what is helpful IMAT 1906 Lecture Week 7 (c) De Montfort University 2010-11

  9. Data requirements • As we identify functional requirements, we also discover data requirements • What data will need to be stored • Data items and how they interrelate • Data needed: input (screens) and output (screens, reports) • Where it will need to be stored for example in a database • Local database on the same computer or server as the system • Remote database on a server not with the system • How long it needs to be kept • How it will be used • How it will be deleted when it is no longer used or valid IMAT 1906 Lecture Week 7 (c) De Montfort University 2010-11

  10. Data protection • Is any of the data sensitive • eg personal data • need permission to hold the data • need to keep it accurate and up to date • data protection act – legislation that protects privacy and data access rights of individuals • Is any of the data confidential • eg company financial targets and transactions • need to control access to the data through access authority limits IMAT 1906 Lecture Week 7 (c) De Montfort University 2010-11

  11. Non-functional requirements • What standards are needed for screen layout and appearance • Are there any known access authority levels • What timing constraints might there be • Can be documented within the relevant requirements catalogue entries • In a large organisation, there might be a reference to an in-house guide or handbook for screen or report design IMAT 1906 Lecture Week 7 (c) De Montfort University 2010-11

  12. Where we are on agenda • Requirements gathering • Fact finding for detailed understanding • Requirements specification • Test strategy • Assignment 2 scenario and tasks IMAT 1906 Lecture Week 7 (c) De Montfort University 2010-11

  13. Factfinding for detailed understanding • Useful techniques • Interviews • Workshops • Questionnaires • Document analysis • Observation • Plus – analysing the results; question format has a bearing on analysing the results IMAT 1906 Lecture Week 7 (c) De Montfort University 2010-11

  14. Interviews 14 IMAT 1906 Lecture Week 7 (c) De Montfort University 2010-11 • We have seen something of interviews in tutorials • Interview is a directed conversation • Basic structure of interview for detailed understanding is similar to interview for overall • Questions now focus on detail • What is done - what tasks do you do every day? • How it is done - how do you process a new order? • When it is done - do orders come in at a specific time? • Peaks - is the work steady or are there busy times? • Interviews can be longer as there is more detail to explore

  15. Workshops 15 IMAT 1906 Lecture Week 7 (c) De Montfort University 2010-11 • Workshop is a directed group conversation • Basic structure of workshop for detailed understanding is similar to workshop for overall • Tends to look at flow of information and work across several teams or areas in a department, or several departments • Questions now focus on detail • What is done - what tasks are carried out in the area? • How it is done - how is a new order processed and filled? • Who is involved - how many teams deal with each order? • Peaks - when is the busiest time? how many orders then?

  16. Questionnaires 16 IMAT 1906 Lecture Week 7 (c) De Montfort University 2010-11 • Series of questions people fill in on their own • Structured questions: • Unambiguous so person can tell what you’re asking • Responses structured in some way • Yes/no • Range eg 1-5 or Often to Seldom • Options eg <5 / 5-10 / 11-15 / >15 • Some free text responses but not too many • Questions about one topic can be grouped together • Relevant to what the respondents do in their work • Clear instructions with return date • Analyse by counting responses in each category

  17. Document analysis 17 IMAT 1906 Lecture Week 7 (c) De Montfort University 2010-11 • Examine samples of documents and records currently being used • Analyse what’s on the document: • Identify things being recorded eg books • Identify data items recorded eg titles and authors • These become input fields and data requirements • Find out who starts the document and where it is sent next • Find out how each area deals with the document • Find out how many are dealt with in a day for example

  18. Observation 18 IMAT 1906 Lecture Week 7 (c) De Montfort University 2010-11 • We may be able to sit alongside a user and watch how they do their work or carry out a function • Make notes • what they do, either what tasks or what steps in a task • how they do it • what they use in order to do the tasks • how often in a time period • how long it takes • who else they need to involve • Need to be careful not to get in the way • Needs permission

  19. Analysing the results 19 IMAT 1906 Lecture Week 7 (c) De Montfort University 2010-11 Whatever we found in the fact finding, we need to analyse the results Some analysis can be done numerically Some needs to be done by looking at notes and lists Question structure can influence the analysis eg yes/no answers are easy to count Use diagrams of various kinds to work out what is needed or what is happening in a scenario Try to summarise and see if it makes sense Go back to the users to confirm misunderstandings or things that aren’t clear

  20. Where we are on agenda • Requirements gathering • Fact finding for detailed understanding • Requirements specification • Test strategy • Assignment 2 scenario and tasks IMAT 1906 Lecture Week 7 (c) De Montfort University 2010-11

  21. Documenting requirements • Requirements list • List of functions or processes users will need • Requirements catalogue • Series of entries one for each requirement on list • Gives details of requirement • Users involved • Priority • Description of task or interaction with user • Inputs and outputs • Process which turns inputs into outputs • Any non-functional aspects of requirement eg frequency, timing IMAT 1906 Lecture Week 7 (c) De Montfort University 2010-11

  22. Logical design • Requirements feed logical design • Data requirements • Inform the database design - E-R model • Inform the interface design - screen and report layouts • Functional requirements • Inform the process logic • Inform the conversation between system and user • Documented in process diagrams • Use case diagrams • Data flow diagrams • Look at these next week IMAT 1906 Lecture Week 7 (c) De Montfort University 2010-11

  23. Where we are on agenda • Requirements gathering • Fact finding for detailed understanding • Requirements specification • Test strategy • Assignment 2 scenario and tasks IMAT 1906 Lecture Week 7 (c) De Montfort University 2010-11

  24. Testing the requirements specification • Check your understanding of business area with the users • Go back to key users and talk them through some of the diagrams to confirm your understanding • Present the requirements specification to key users and check they agree the requirements are correct • Find out about any changes or corrections needed • Better to find out at this stage than later: the earlier we discover mistakes the easier and less expensive it is to fix them IMAT 1906 Lecture Week 7 (c) De Montfort University 2010-11

  25. Test strategy • Use requirements specification to design test strategy and plans • Each requirement suggests several tests • Correct data in however many options there may be • Incorrect data in however many ways errors might happen • Check that each requirement is covered by at least one test and each test covers at least one requirement • Ask two questions: • How will we know the system does what’s required • How will users know the system does what’s required IMAT 1906 Lecture Week 7 (c) De Montfort University 2010-11

  26. Types of testing • Unit testing - each function or process or screen • System testing - correct links between functions • End-to-end testing - from initial input to final output • User acceptance testing • Users run their own tests based on real cases • Checks that system works for them and fits their work flow • Operational acceptance testing • Usual in large organisations • Checks that system operates on large scale • Checks that system does not interrupt other systems running at the same time IMAT 1906 Lecture Week 7 (c) De Montfort University 2010-11

  27. Test plan • Test cases – this is the test data • Test plan – this is the test scripts with suggested inputs and expected outputs • Test log – this is the record of actual results from the tests – include the tests that fail too, so you know what you had to go back and redo – sometimes also note what had to change in order to make the test work (eg errors in code) • Testing can be automated, with test cases stored for repeated use IMAT 1906 Lecture Week 7 (c) De Montfort University 2010-11

  28. References – for more information • Skidmore & Eva • Chapter 5 • Data protection act pp 247-252 • Shelly & Rosenblatt • Chapter 4 • Cadle, Paul & Turner • Chapter 6 IMAT 1906 Lecture Week 7 (c) De Montfort University 2010-11

  29. Where we are on agenda • Requirements gathering • Fact finding for detailed understanding • Requirements specification • Test strategy • Assignment 2 scenario and tasks IMAT 1906 Lecture Week 7 (c) De Montfort University 2010-11

  30. Assignment 2 outline • Group work • Due 9 Dec week 10 • Case study with supporting documents • Assignment tasks • Hand in to Student Advice Centre, use gold card assignment cover sheets and group assignment submission sheet IMAT 1906 Lecture Week 7 (c) De Montfort University 2010-11

  31. Assignment 2 case study outline • Ferret Rescue Society • Scenario • Rescue centre • Activities: house ferrets, assess them as pets, assess their health and treat if necessary, find them homes • Need for new system • Supporting documents • Ferret record sheet • Potential new order record • Adoption agreement – when ferret has been rehomed • List of vets • List of trainers IMAT 1906 Lecture Week 7 (c) De Montfort University 2010-11

  32. Assignment 2 tasks • Analysis • Analyse scenario and make notes of requirements • Analyse documents and make notes of requirements • Discuss among group • Rich picture • Requirements list • Detailed requirements specifications • Initial logical design • Analyse again • Use case diagram (Qsee) • Use case descriptions (Word) IMAT 1906 Lecture Week 7 (c) De Montfort University 2010-11

More Related