Identifying and Prioritising System Requirements: INFS 1026 SRUX Lecture 4
"Learn how to identify and prioritize system requirements through research techniques, business requirements, user requirements, and functional requirements. Understand the importance of defining what a system should do and how it should behave. Get insights into FURPS+ and examples of functional requirements in systems like Moodle."
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
INFS 1026 Systems Requirements and User Experience - SRUX Lecture 4: Identifying and Prioritising Requirements
2 Recap Research Field studies Diary studies Interviews Other information gathering techniques Outputs from research Information to identify requirements
3 Requirements Business Requirements Represent in problem statement Why is the system necessary? What benefits are anticipated? User Requirements Requirements identified by users specific to their system use and needs Source: Misfud n.d. Misfud n.d.;Wiegers & Beatty 2013
4 System Requirements Requirements are a specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute. They may be a constraint on the development process of the system (Sommerville & Sawyer cited in Wiegers & Beatty 2013, p. 6) System requirements are the specifications of the system which must be met for the completed system Represented by FURPS+ acronym Wiegers & Beatty 2013
5 Functional Requirements - FURPS+ What the system must do under specific conditions What functions / tasks must the system perform to satisfy user requirements? What interactions are required with other systems? What not how No details of steps taken to perform the task Format FRx: The system shall <statement> FR1: The system shall maintain student course details Wiegers & Beatty 2013
6 Functional Requirements - FURPS+ FR1: The system shall allow teaching staff to maintain student assignment grades Brief and to the point SMART covered later Often can translate to a menu item maintain implies create, update or delete Wiegers & Beatty 2013
7 Functional Requirements - FURPS+ Example Moodle / Learning Management System FR1: The system shall allow students to enrol in courses FR2: The system shall allow teaching staff to maintain student attendance FR3: The system shall allow learning materials to be downloaded FR4: The system shall enable students to maintain their assignment submissions if before the due date Wiegers & Beatty 2013
8 Functional Requirements - FURPS+ Divided to subsystems, numbering still continuous Enrolments subsystem FR1: The system shall allow students to enrol in courses Attendance subsystem FR2: The system shall allow teaching staff to maintain student attendance Content subsystem FR3: The system shall allow learning materials to be downloaded Assessment subsystem FR4: The system shall enable students to maintain assignment submissions if before the due date Wiegers & Beatty 2013
9 Non-functional Requirements FURPS+ Non-functional requirements .. properties that make the system suitable and maybe even enjoyable - for use by intended operators (Wiegers & Beatty 2013, p. 6) Characteristic a system must have or a constraint it must meet Intuitively associated to user experience definitions Used to judge the quality of the system operation Wiegers & Beatty 2013
10 Non-functional Requirements FURPS+ Format <Category> NFRx: The system must <statement> Numbering still continuous across categories Final number represents the total number of non-functional requirements for the system Wiegers & Beatty 2013
11 Non-functional Requirements FURPS+ Usability Usability what the system is used for Part of user experience lecture 1 According to Nielsen (1993) usability means the system must be Easy to learn Efficient to use Easy to remember Few errors Subjectively pleasing Nielsen 1993
12 Non-functional Requirements FURPS+ Usability Common characteristics to consider Colour scheme, layout and other UI elements Conventions and standards Organisation style guide Human interface guidelines and accessibility eg Vision impaired and colour blindness considerations Training and help provisions Accuracy Wiegers & Beatty 2013
13 Non-functional Requirements FURPS+ Usability NFR1: The system must provide dropdowns for easy selection from between 3 and 10 values NFR2: The system must provide alternate descriptions for all elements on a screen for use by people who are vision impaired Wiegers & Beatty 2013
14 Non-functional Requirements FURPS+ Reliability Acceptable levels of availability of the system Usually dependant on the time period when the system must be available Consider mean time before / between failures (MTBF) Consider accuracy of the system Security requirements such as strong passwords, SSL and access restrictions Backup and recovery procedures Wiegers & Beatty 2013
15 Non-functional Requirements FURPS+ Performance Relates to the response speed and throughput of the system 1993 Jakob Nielsen wrote Usability Engineering The basic advice regarding response times has been about the same for thirty years (Nielsen 1993) Defined important time measurements 0.1 second impression of instant reaction 1 second limit for user flow of thought 10 seconds limit to keep user attention Nielsen 1993;Wiegers & Beatty 2013
16 Non-functional Requirements FURPS+ Performance Measure of throughput How many transactions should occur in a specified time span What is the expected data transmission rate Measure of capacity Number of concurrent users the system can accommodate Number of transactions the database can accommodate Scalability How does it handle an increase in the number of users? Failure detection What fall backs are used to prevent total failure from occurring? What recovery processes are in place? Wiegers & Beatty 2013
17 Non-functional Requirements FURPS+ Often challenging to differentiate between reliability and performance Reliability NFR4: The system must be available with 99.9% uptime at a peak load of 300 concurrent users. NFR5: The system must run a scheduled backup every night to cloud storage Performance NFR6: The system must provide feedback to user input within 10 ms during standard use NFR7: System responses must decrease by a maximum of 5ms for each additional 1000 simultaneous users Wiegers & Beatty 2013
18 Non-functional Requirements FURPS+ Supportability Ease of upgrading or modifying the system in the future Level of operational support needed by the customer such as installing upgrades and fixing bugs + Design constraints related to hardware, software or network requirements Regulations and standards which must be followed Technology the system must operate on Software the system must integrate with Environment in which the system must operate Wiegers & Beatty 2013
19 Non-functional Requirements FURPS+ Supportability NFR8: The system must have a backup processes to enable continuation of business processes in case of a main system failure NFR9: The system must maintain an audit trail to enable reprocessing of transactions to the time of failure using the previous night s backup + Design Constraints NFR10: The system must be usable on any internet enabled device NFR11: The system must interface with Xero for accounting functions Wiegers & Beatty 2013
20 FURPS+ + Design Constraints NFR15: The system must be usable on any internet enabled device NFR16: The system must interface with Xero for accounting functions NFR17: The system must enable graphics and other website content to scale depending on the display size and processing speed of the hardware in use Wiegers & Beatty 2013
21 SMART Requirements Specific Clear, consistent, simple / single not double, concise Measurable How do you measure that the requirement is implemented? Attainable Realisable Time bound or Traceable Wiegers & Beatty 2013
22 SMART Requirements https://www.youtube.com/watch?v=urcQAKKAAl0
23 SMART Requirements Specific Requirements guidelines Specify units where necessary Do not use etc , and others , such as Defined terms in a glossary for clarification and consistency Qualify verbs transmitted , sent , downloaded , processed are with precise explanations what is transmitted etc No To be defined statements Clearly identify what details , information , date are to be used Use objective, not subjective terms such as nice , fast , easy to use FR1: The system shall show the details of the patient when the user selects the patient from the patient list. What details? A lot of data is kept about patients Wiegers & Beatty 2013
24 SMART Requirements Measurable Can software tests be written to verify requirement is achieved NFR2: The system must have no single point failures How can we ever measure that there is no single point of failure? It is an open problem Attainable The requirement must be physically achievable NFR3:The system must run on an iPhone4 at 120 frames per second with 10 million triangles drawn on screen This is not physically possible based on the limits of the hardware Wiegers & Beatty 2013
25 SMART Requirements Realisable Is the requirement realistic given the resources allocated and constraints applied Time, human resources, knowledge / experience, technology Consider a 2 month first year student project NFR5: The system shall use the camera component to create a 3D reconstruction of the world in the shared database Requirement is achievable but not realisable within the project constraints Wiegers & Beatty 2013
26 SMART Requirements Traceable Audit checks must be possible to ensure standards are in place Provide a reason why a requirement is included NFR8: The system must have a backup system in place to enable continuation of business processes in case of a main system failure Wiegers & Beatty 2013
27 Writing Good Requirements Good requirements Avoid the use of subjective words Easy, simple, fast Be specific / use objective words learn x activities in y hours respond to input in x seconds enable x concurrent users without performance degradation Are attainable within time and budget of the project Use simple sentences Wiegers & Beatty 2013
28 Writing Good Requirements Use consistent, standard language Use the same terminology throughout your requirements Define terminology in a glossary Use active voice instead of passive voice The system shall return the search results at latest 30 seconds after the user has entered the search criteria active voice The search results shall be returned no later than 30 seconds after the user has entered the search criteria passive voice Avoid using / to show alternatives which can be ambiguous Is this a functional / system need? Mannion & Keepence 1995;Wiegers & Beatty 2013
29 Writing Good Requirements Common problems Bad assumptions Writing implementation requirements How it is to be provided instead of what is to be provided FR1: The system shall provide a database Using incorrect terms, spelling, grammar, sentence structure Describing operations instead of requirements or over specifying Describing all steps to perform the task in one requirement when this is what needs to be further analysed Missing requirements Wiegers & Beatty 2013
30 Prioritising Requirements Wiegers & Beatty 2013
31 Prioritising Requirements Need to aim for the system to deliver the most critical or valuable functionality as early as possible (Wiegers & Beatty ) Time and cost limitations usually prevent absolutely every need Success depends on Understanding user needs Understanding importance of requirements to customers Time to complete the system release Requirements which must be implemented in a natural order Requirements which must be grouped Cost necessary to implement requirements Wiegers & Beatty 2013
32 Prioritisation Challenges User priority often does not fit with other s priorities Need good communication Understand the cost and technical challenge and risk of requirements and where compromise is possible Ask leading questions (Wiegers & Beatty 2013, p. 317) Is there another way to satisfy the need met by this requirement? What are the consequences of deferring / delaying the requirement? How would the project s business objectives be effected if the requirement was deferred? Why does the customer not want to wait for the next release? Is the feature worth delaying all features with the same priority? Wiegers & Beatty 2013
33 Prioritisation Techniques MoSCoW Must be included for the solution to be successful Should be included but is not mandatory for success Could be delayed, implement only if time and resources allow Won t be implemented at this time but could be included in a future release Generally no time put on this, could mean never Stakeholders will avoid because want to know when Wiegers & Beatty 2013
34 Prioritisation Example Number Requirement M S C W Justification This must be included because this information is created each time a new experiment is conducted in the lab because of different chemical dangers, reactionsand precautions. This must be included to allow chemists to schedule jobs based on order deliveries This must be done to ensure all chemicals have been correctly signed for and process is being followed This should be done but alternative reports could provide this information - inventory This should be done to save time and avoid unsuccessful orders. Low priority since new chemicals are rarely used in the laboratory This could be included but the same information is attainable from other summary reports. This won't be included because the suppliers will not allow it. The system shall allow chemists to print a material safety data sheet The system shall allow chemists to query the status of a vendor order The system shall generate a chemical stockroom inventory report each week The system shall display the history of a specific chemical container FR1 x FR2 x FR3 x FR4 x The system shall allow chemists to search vendor catalogues for a specific chemical The system shall allow chemists to maintain a list of hazardous chemicals The system shall allow chemists to change a pending chemical request FR5 x FR6 x FR7 x This must be done to ensure all chemicals have been correctly allocated to experiments and process is being followed The system shall generate a laboratory inventory report each week FR8 x Wiegers & Beatty 2013
35 Other Prioritisation Techniques In or Out Simplest prioritisation Work through each requirement Decide if in or out Difficult if multiple stakeholders Pairwise comparison Compare each requirement Decide which is more important Becomes unwieldy for more than about 20 requirements Wiegers & Beatty 2013
36 Other Prioritisation Techniques $100 Each stakeholder has $100 and can allocate some of that to each requirement The more they allocate, the higher priority they consider the requirement Challenging to track how much has been allocated and how much remains Wiegers & Beatty 2013
37 Other Prioritisation Techniques Value / Cost / Risk Analysis Value a feature against cost and risk Apply a weight to each to determine priority Wiegers & Beatty 2013
38 References Leffingwell, D 2010, Agile software requirements: Lean requirements practices for teams, program and the enterprise, 1st Edn, Pearson Education Limited, Upper Saddle River, NJ. Mifsud, J n.d., Requirements gathering: A step by step approach for a better user experience (Part 1) , UsabilityGeek, viewed 01 February 2022, <https://usabilitygeek.com/requirements-gathering-user-experience-pt1/>. NASA Safety Center 2009, Lost in translation , System Failure Case Studies, vol. 3, no. 5, viewed 19 February 2021, <https://sma.nasa.gov/docs/default-source/safety- messages/safetymessage-2009-08-01- themarsclimateorbitermishap.pdf?sfvrsn=eaa1ef8_4>. Nielsen, J 1993, Usability engineering, Academic Press, Cambridge, MA, O Riley Media. Wiegers, K & Beatty, J 2013, Software requirements, 3rd edn, Microsoft Press, Boston USA. Wiegers & Beatty 2013
