Lecture 5A: System Requirements

Lecture 5A: System Requirements CMP-4013A SYSTEMS DEVELOPMENT ELEANOR LEIST 1 Learning Outcomes 1) Recognise the importance of requirements to the success of a system 2) Categorise requirements as functional and non- functional 3) Prioritise requirements appropria...

Lecture 5A: System Requirements CMP-4013A SYSTEMS DEVELOPMENT ELEANOR LEIST 1 Learning Outcomes 1) Recognise the importance of requirements to the success of a system 2) Categorise requirements as functional and non- functional 3) Prioritise requirements appropriately, according to importance 2 Overview Introduction to requirements Gathering requirements Requirement analysis and prioritisation Requirements in traditional and iterative approaches Example: Timetabling system 3 Introduction to Requirements 4 What are requirements? A set of requirements describes the required functionality of a A capability, system characteristic, Can cover many things: or constraint ◦What the system will do that a system ◦How it will do it must meet to ◦How it will work function ◦What it will look like properly. 5 Requirements… o Are key to the success of a system o Are the main link between the customer and the development team o Translate user needs into system specifications o Won’t always been finalised at the start of the project 6 Difficulties with requirements Small People don’t mistakes = know what big impact they want later Hard to get And they right the first want time different things! 7 Gathering Requirements 8 Gathering requirements o Stakeholders may have a woolly view of the system o Even if they know what they want, they may not be able to describe it! o The requirements gathering process should be: o Organised o Iterative o Easy to understand 9 Requirements can be gathered by… Intervie Worksho ws ps Observatio Documentati ns on Questionnair Existing es systems 10 Deciding how to investigate o Identify all stakeholders: o Managers – budget holders Customers Partners o Users – working with the system Competitor Suppliers o Suppliers – providing inputs s o Customers – getting outputs Owners Regulators o Not all stakeholders are equal ManagersEmployees o Cannot please all people all of the time o Perform stakeholder analysis to choose the best approach 11 Requirement Analysis and Prioritisation 12 Starting requirement analysis Requirements can be:  Missing – even the best analyst isn’t psychic!  Poor quality – difficult to understand, vague, ambiguous, hard to measure  Infeasible, impossible or irrelevant Need to identify and correct issues ASAP 13 Fixing poor quality requirements The system The system The system must should allow should be easy work well on any users to manage to use mobile device their orders The system The system Users can amend should allow should be the delivery date users to compatible with of their order Users can cancel complete key smartphones an order within functions in running iOS 12+ 24 hours of under 4 steps or Android 8+ placing it 14 What happens next? o Move from high level broad aims and goals to specific requirements o Classify into: o Functional – what the system will do o Non-functional – how the system does it o Gather all requirements into a comprehensive list o Outputs are used for formal system designs 15 Prioritisation o Cannot implement all requirements o With customer, decide importance levels and order of completion o Method will depend on approach being used o This module teaches MoSCoW: Must Should Could Won’t have have have have 16 MoSCoW analysis o Absolutely critical, essential to the Must have system o Deal-breakers, must be delivered o Should ideally have these, would Should expect them have o May be prioritised within this Could o Optional extras, nice to have have Won’t o Not to be implemented this time have o Still valid requirements 17 Prioritising requirements For a university learning system (i.e. Blackboard):  What would the essential requirements be?  What would the important requirements be?  What would be nice to have?  Would wouldn’t you prioritise? 18 Requirements and the Development Process 19 Changing requirements o Requirements inevitably change o Sometimes this is good “I understand this better now. Let’s update…” o But often it is not! “We’ve now “We got it “I forgot to “I changed been told it wrong. ask…” my mind…” must…” Actually…” 20 Traditional approach Requirem System developm System ents ent magic Feasibility Analysis Design Implement Test Maintain 21 Iterative approach Design Gather Analyse Confirm Develop / Collate feedbac k Test 22 Requirements in iterative development An iterative requirements process allows: o Continuous refinement o Constant checking/rechecking for suitability o Easier/earlier identification of mistakes o More flexibility for requirements change o Ability to prototype requirements, system parts, whole system o Better visibility 23 So what next? Requirements must be monitored ◦Control changes carefully throughout development ◦Avoid scope creep! ◦Version control and traceability are key 24 Requirements Example 25 Timetabler o Central location for all things timetable-related o Students and staff can view their timetables o Timetabling leads can see draft versions of the timetable before they are released to staff and students o LTS timetabling team members have the power to edit events o But staff need to request changes via MS Teams o And Timetabler is not without its issues 26 Why is change needed? o Incompatible with mobile use o Sometimes shows different information than Outlook or Teams o Can be very complex and challenging to use (if not an expert!) Aim: Fix the problems and have one system that works for everybody. 27 Stakeholders University LTS School FPS Timetablin managem timetablin staff/admi g leads ent g team n Teaching Estates Students Security staff team 28 Gathering views o Show full timetable in different formats Students o Able to view easily on smartphone o Notified of any changes o Easily request change to event o View current requests and Timetablin status g leads o Move students between sessions 29 Requirements R1: All users able to view timetable R2: Compatible with smartphones R3: All staff able to request changes to events R4: Staff and students notified of any changes to events R5: Access control to ensure no unauthorised use of features R6: Accessibility settings to adjust view R7: Able to move students between teaching sessions 30 Categorising Functional Non-functional Able to view timetable (R1) Compatible with Able to request changes smartphones (R2) (R3) Notifications of changes Access control to ensure to events (R4) no unauthorised use (R5) Able to move students Accessibility settings to between sessions (R7) adjust view (R6) 31 MoSCoW o Access control Must have o View timetable o Staff able to request changes to Should have events o Notifications of changes to events o Accessibility settings to adjust view Could have o View history of requests o Able to move students between Won’t have sessions 32 Summary o Requirements = key to the success of a system o Defining requirements should be done systematically Stakeholder analysis and involvement Assess, combine, prioritise Iterate, get feedback, prototype o Flexible development model supports flexible requirements o Be aware that requirements can and will go wrong! 33 Lecture 5B: Use Case Modelling CMP-4013A SYSTEMS DEVELOPMENT ELEANOR LEIST 34 Learning Outcomes 1) Identify use cases and draw a simple use case diagram 2) Create textual use case descriptions to provide more detail on use cases 35 Overview Introduction to use cases Use case diagrams Textual use cases Example: Marketplace app 36 Introduction to Use Cases 37 What are use cases? o Most systems involve interaction with users and other systems o These interactions need to be documented o Use cases describe the sequence of events to yield a result o Need to consider flow to/from the system, and possible outcomes (including failure!) 38 What is an actor? ◦Usually a human user Actor: ◦A role, not a person Someone or something that ◦Can be another interacts with a system system ◦Example: Customer 39 What is a use case? ◦A way in which a Use case: user may interact An activity that with a system the system carries out in response to ◦An action a request from an undertaken on a actor system to achieve a goal ◦Example: Place 40 Proper use cases should… Capture: Who (actor) does what (interaction) with the system for what purpose (goal) A complete set of cases should: o Specify all the different ways to use the system o Define all the behaviour required of the system 41 Use case index o AKA use case list o A list of all use cases can be kept in an index o Helps to organise and manage cases o Should have ID, Name, Primary Actor, Complexity and Priority ID Name Primary Complexi Priority ty 1 Place order Customer High 1 2 Check Customer, sales Low 2 availability assistant … … … … … 42 Use Case Diagrams 43 What is a use case diagram? o A simple diagram showing a high-level overview of all use cases o Models all functionality of a system from the users’ point of view o One diagram for whole system o Shows how actors interact with the system o No detail given about steps within use cases 44 Why are use case diagrams useful? Helps Visual identify scope Clear and Discover concise requirem ents 45 Use case diagram notation Example: “The customer Actor Use uses the system to place an case order” Simple notation is used: Place order ◦Stick figures to represent actors Customer ◦Ovals representing the use Associat cases ion ◦Lines representing associations 46 Use case diagram notation Sales System System name Check availabilit y Place Customer order Sales assistant System Update boundary order 47 Includes One use case may require another to be done as part Check of it availabilit ◦Example: Place order y >> requires Check availability es ◦Place order cannot be done lud without checking availability inc first > an extension of Update order ds ◦Whilst updating an order the ten ex supervisor has the option to