{"id":31,"date":"2023-09-04T18:36:20","date_gmt":"2023-09-04T18:36:20","guid":{"rendered":"https:\/\/libraryresources.nse.org.ng\/setextbook\/chapter\/requirements\/"},"modified":"2026-03-16T14:20:47","modified_gmt":"2026-03-16T14:20:47","slug":"requirements","status":"publish","type":"chapter","link":"https:\/\/libraryresources.nse.org.ng\/setextbook\/chapter\/requirements\/","title":{"raw":"Requirements","rendered":"Requirements"},"content":{"raw":"<div class=\"imgbleed\"><a href=\"https:\/\/open.oregonstate.education\/app\/uploads\/sites\/174\/2023\/09\/CoverChapter04.png\"><img class=\"aligncenter size-full wp-image-29\" src=\"https:\/\/libraryresources.nse.org.ng\/wp-content\/uploads\/sites\/16\/2023\/09\/CoverChapter04.png\" alt=\"Chapter cover\" width=\"2550\" height=\"1320\"><\/a><\/div>\n<h2 class=\"chtitle\">Chapter 3\nRequirements<\/h2>\nA software [pb_glossary id=\"883\"]requirement[\/pb_glossary] is a rule the software must conform to: what it must do, how well, and within what [pb_glossary id=\"838\"]constraints[\/pb_glossary] or limits.\n<h1>3.1 Types of Requirements<\/h1>\nThere are two main <strong>types of requirements<\/strong>:\n<ol>\n \t<li>[pb_glossary id=\"839\"]Functional requirements[\/pb_glossary] are \u201cA description of a behavior that a system will exhibit under specific conditions\u201d (Wiegers &amp; Beatty, <span class=\"citation\">[pb_glossary id=\"663\"]2013[\/pb_glossary]<\/span>, p. 599). For example, \u201cIf the user activates the \u2018log in\u2019 button, the login page will appear.\u201d Functional requirements answer the question, \u201cWhat must the software do?\u201d<\/li>\n \t<li>[pb_glossary id=\"840\"]Nonfunctional requirements[\/pb_glossary] are \u201cA description of a property or characteristic that a system must exhibit or a constraint that it must respect\u201d (Wiegers &amp; Beatty, 2013, p. 600). For example, \u201cIf the user activates the \u2018log in\u2019 button, the login page will appear within 500 milliseconds.\u201d This nonfunctional requirement has a characteristic that the system must exhibit: responsiveness. Responsiveness is also called a [pb_glossary id=\"841\"]quality attribute[\/pb_glossary]. An example of a nonfunctional requirement about respecting a constraint is, \u201cThe GUI toolkit must be able to display non-rectangular windows.\u201d<\/li>\n<\/ol>\nFigure 3.1 shows a simple example of a design failing to reflect a nonfunctional requirement and a functional requirement.\n<div class=\"largeimg\">\n\n[caption id=\"attachment_101\" align=\"aligncenter\" width=\"2279\"]<a href=\"https:\/\/open.oregonstate.education\/app\/uploads\/sites\/174\/2023\/09\/Fig04.01.png\"><img class=\"size-full wp-image-30\" src=\"https:\/\/libraryresources.nse.org.ng\/wp-content\/uploads\/sites\/16\/2026\/03\/Fig04.01.png\" alt=\"Sketch of house\" width=\"2279\" height=\"1721\"><\/a> <strong>Figure 3.1<\/strong> Two Failed Requirements[\/caption]\n\n<\/div>\n<em>Note.<\/em> This rolling table fails the nonfunctional requirement of fitting through an average door and the functional requirement of having four legs.\n<h1>3.2 Why Requirements Matter<\/h1>\nThe design and implementation of software should, ideally, follow from the requirements. Here are some <strong>ways requirements are helpful<\/strong> and reasons they are important:\n<ul>\n \t<li>When developers aren\u2019t given requirements, they <strong>might prioritize functionality they personally think is important or fun<\/strong> to implement, but what developers want to implement might not make the project successful.<\/li>\n \t<li>When multiple developers are working on the same code, requirements can <strong>help them stay in sync<\/strong> and <strong>pursue the same goal<\/strong>. Without requirements, time, effort, and money can be wasted implementing conflicting code.<\/li>\n \t<li>When requirements aren\u2019t specified, it\u2019s easier for project [pb_glossary id=\"842\"]stakeholders[\/pb_glossary] (e.g., [pb_glossary id=\"843\"]clients[\/pb_glossary], partners, investors, consultants, management) to <strong>influence the project toward satisfying their own<\/strong> (possibly fleeting) <strong>wants or needs<\/strong>. This can result in the project drifting away from what it was originally intended to do\u2014and can lead to project failure.<\/li>\n \t<li>Requirements are <strong>helpful for communicating<\/strong> about software with stakeholders, <strong>keeping track<\/strong> of everything that needs to get done, and helping you and the client <strong>decide what really needs to get done<\/strong> (clients sometimes don\u2019t know what they really need).<\/li>\n<\/ul>\n<h1>3.3 What Makes a Good Requirement<\/h1>\nTeams or organizations can choose their own standards for what makes a good requirement. Here is <strong>one set of standards<\/strong> (Texas Department of Information Resources, <span class=\"citation\">[pb_glossary id=\"660\"]2008[\/pb_glossary]<\/span>):\n\n<strong>Requirements should be<\/strong> . . .\n<ul>\n \t<li><strong>Correct<\/strong>: What they say is right.<\/li>\n \t<li><strong>Unambiguous<\/strong>: There is only one way to interpret them.<\/li>\n \t<li><strong>Complete<\/strong>: They cover all that\u2019s important.<\/li>\n \t<li><strong>Consistent<\/strong>: They aren\u2019t contradictory.<\/li>\n \t<li><strong>Ranked for importance and\/or stability<\/strong>.<\/li>\n \t<li><strong>Verifiable<\/strong> <strong>or testable<\/strong>: There\u2019s a way to figure out if they\u2019re satisfied.<\/li>\n \t<li><strong>Modifiable<\/strong>: They can be changed.<\/li>\n \t<li><strong>Traceable<\/strong>: It\u2019s possible to figure out where they came from.<\/li>\n<\/ul>\nRequirements should also be . . .\n<ul>\n \t<li><strong>Cross-referenced to earlier documents<\/strong> that relate.<\/li>\n \t<li><strong>Uniquely identifiable<\/strong>.<\/li>\n \t<li><strong>Organized for maximum readability.<\/strong><\/li>\n<\/ul>\n<h1>3.4 Requirements Elicitation<\/h1>\n<p class=\"page-break-after\">The process of gathering requirements is called [pb_glossary id=\"844\"]requirements elicitation[\/pb_glossary]. Requirements can come from any stakeholder, including clients, managers, users, governments, developers of software to be integrated with yours, the development team, and yourself. Requirements elicitation involves both detecting stakeholders\u2019 wants and needs and using your professional judgment to decide which requirements to focus on.<\/p>\n<strong>To detect stakeholders\u2019 wants and needs<\/strong>, communicate and observe. Some methods:\n<ul>\n \t<li><strong>Interviews<\/strong>: Structured (questions defined ahead of time), semi-structured (some questions predefined, some generated during interview), or unstructured conversations.<\/li>\n \t<li><strong>Focus groups<\/strong>: Small, group conversations in which the participants discuss topics among themselves, with moderator guidance.<\/li>\n \t<li><strong>Lab studies<\/strong>: Participants perform tasks in a controlled setting (e.g., try to use an early prototype, then give feedback).<\/li>\n \t<li><strong>Exploratory research<\/strong>: Multiple methods of immersing oneself within the world of relevant people and products, with the purpose of gaining knowledge and developing empathy for stakeholders. For example, after doing a fly-on-the-wall observation, you realize that people can\u2019t find Aisle 25 because it\u2019s in an unexpected place. You decide to prioritize the Aisle Map feature in the store\u2019s app.<\/li>\n<\/ul>\nDepending on the software development environment, <strong>these methods might be the jurisdiction of specialist researchers in marketing or interaction design<\/strong>. Hanington and Martin (<span class=\"citation\">[pb_glossary id=\"652\"]2019[\/pb_glossary]<\/span>) describe these specialist methods (and many other relevant methods) in more detail.\n\n<strong>Developers can elicit requirements, too<\/strong>, by having conversations with stakeholders. There are <strong>factors that can affect the success <\/strong>of that approach, however.\n<ul>\n \t<li><strong>Stakeholders might not have experience or expertise<\/strong>. Developers can help bridge the gap between what the stakeholder wants and what is technically feasible and reasonable (e.g., given time, cost, and scope, what is also known as the triple constraint).<\/li>\n \t<li><strong>Stakeholders might not have good ideas<\/strong>. They might be incorrect about what they or other people want or will use. Developers can sometimes provide guidance toward better ideas, but developers can also have bad ideas. Methods such as focus groups, [pb_glossary id=\"846\"]usability testing[\/pb_glossary], and releasing a [pb_glossary id=\"847\"]minimum viable product (MVP)[\/pb_glossary] can help with figuring out whether users will use (and pay for) the software.<\/li>\n \t<li><strong>Stakeholders might not know what they want<\/strong>. They may have a rough idea, or an idea that\u2019s at odds with their wants or needs.<\/li>\n \t<li><strong>Stakeholders might want what\u2019s bad for them or others<\/strong>. For example, users want apps that make their face beautiful in photos, such features may promote unrealistic beauty standards.<\/li>\n \t<li><strong>Stakeholders are humans<\/strong>. They communicate imperfectly.<\/li>\n<\/ul>\nWith experience, you can learn how to effectively gather relevant information from stakeholders and make your own judgments about how that information translates into requirements.\n<h1>3.5 Nonfunctional Requirements<\/h1>\nNonfunctional requirements describe how well the software needs to perform or what constraints it must respect.\n\n<strong>Examples of nonfunctional requirements<\/strong>:\n<ul>\n \t<li>Response time should be a few seconds or less in all operating environments.<\/li>\n \t<li>The front-end design must be evaluated using the [pb_glossary id=\"848\"]Inclusivity Heuristics[\/pb_glossary] by at least two people each [pb_glossary id=\"849\"]Sprint[\/pb_glossary].<\/li>\n \t<li>The software must be available 24 hours a day, seven days a week, and must have an uptime of 99.99%.<\/li>\n<\/ul>\nNotice that <strong>each nonfunctional requirement has a quantity<\/strong>. That helps make it testable (a criterion for a good requirement).\n<h2>3.5.1 Quality Attributes<\/h2>\n<div class=\"textbox textbox--sidebar\">There is a long list of quality attributes on Wikipedia\u2019s \u201c<a href=\"https:\/\/en.wikipedia.org\/wiki\/List_of_system_quality_attributes\">List of system quality attributes<\/a>\u201d page (Wikimedia Foundation, <span class=\"citation\">[pb_glossary id=\"664\"]2023[\/pb_glossary]<\/span>).<\/div>\nQuality attributes are words for describing \u201ca service or performance characteristic of software\u201d (Wiegers &amp; Beatty, 2013, p. 601). <strong>Some common quality attributes <\/strong>are as follows.\n<ul>\n \t<li><strong>Maintainability<\/strong>: Amount of effort needed for developers to update, refactor, or otherwise modify the software\u2019s code.<\/li>\n \t<li><strong>Portability<\/strong>: Amount of effort needed to run the software on different platforms.<\/li>\n \t<li><strong>Reliability<\/strong>: How often the software\u2019s functions succeed or fail.<\/li>\n \t<li><strong>Efficiency<\/strong>: Number of resources the software requires.<\/li>\n \t<li><strong>Integrity<\/strong>: How frequently the software loses data.<\/li>\n \t<li><strong>Memorability<\/strong>: Amount of time users must spend relearning functionality.<\/li>\n \t<li><strong>Flexibility<\/strong>: Number of different ways the software can be used.<\/li>\n \t<li><strong>Interoperability<\/strong>: Ease with which the software can integrate with other software.<\/li>\n \t<li><strong>Reusability<\/strong>: Extent to which the code can easily be used to solve other problems.<\/li>\n<\/ul>\nEach quality attribute can be converted to a scale. For example, the lowest value on a reliability scale for a single could be \u201cthe function succeeds 0% of the time,\u201d and 100% would of course be the opposite pole. Given this scale, we can specify a nonfunctional requirement by defining a performance threshold:\n<ul>\n \t<li>The function must have high reliability (succeeds &gt;99% of the time).<\/li>\n<\/ul>\nWhen you select quality attributes for your software, you are prioritizing what qualities matter most to you\/your team\/the project. Ideally, your team would keep these quality attributes (and the corresponding nonfunctional requirements) in mind for the duration of the project. If the software is not meeting the nonfunctional requirements, either the software or the threshold of acceptability needs to change.\n<h2>3.5.2 Constraints<\/h2>\nSome nonfunctional requirements are not about quality attributes and are instead about staying within constraints. The following are <strong>example types of constraints<\/strong> (Wiegers &amp; Beatty, 2013):\n<ul>\n \t<li>Those limiting technology choices (programming languages, frameworks, databases, application programming interface (API) types, etc.).<\/li>\n \t<li>Those limiting what platforms are targeted (e.g., mobile versus desktop, iOS versus Android).<\/li>\n \t<li>Those limiting what about the software can change (e.g., for backward compatibility).<\/li>\n \t<li>Those limiting how code can be written (e.g., following particular coding and documentation standards).<\/li>\n \t<li>Those limiting how data can be handled (e.g., must only be stored on US servers).<\/li>\n<\/ul>\nA conceptual difference between constraints and quality attributes is that constraints are often externally mandated, while quality attributes can be chosen internally by the team.\n<h1>3.6 Functional Requirements<\/h1>\nFunctional requirements described what the software must do.\n\n<strong>Example functional requirements<\/strong>:\n<ul>\n \t<li>When the \u201cregister\u201d button is activated, the user\u2019s information is added to the database and a \u201cthank you for registering\u201d screen displays.<\/li>\n \t<li>As a wholesaler, I want to see the wholesale and retail prices when I go to \u201cproduct view\u201d so that I know how much money I\u2019m going to make.<\/li>\n \t<li>Given a user has performed at least one editing action, when they activate the \u201caction history\u201d window, they see a list of editing actions they have taken.<\/li>\n<\/ul>\nEach of these functional requirements is formatted differently. There isn\u2019t a name for the first format; it simply states what should happen when a particular action is taken in the software. The second uses [pb_glossary id=\"850\"]user story[\/pb_glossary] format, which is common in Agile software development. This format emphasizes the user, what the user is trying to do, and their motivations. The third requirement uses the [pb_glossary id=\"851\"]given-when-then[\/pb_glossary] format (see <span class=\"citation\">Agile Alliance <\/span>for more information), which incorporates context. This format is commonly used to write user story [pb_glossary id=\"852\"]acceptance criteria[\/pb_glossary]: a set of statements that, when true, indicate that the user story has been completed.\n<p class=\"page-break-after\"><strong>A more formal way to write functional requirements<\/strong> is the [pb_glossary id=\"853\"]use case[\/pb_glossary] format, which follows a template. Figure 3.2 contains an <strong>example use case using a simple template<\/strong>.<\/p>\n\n<div class=\"boxcontainer\">\n<div class=\"textbox textbox--sidebar left boxfigure\">\n\n<strong>Name<\/strong>: Generate list of recovered patients\n\n<strong>Actor<\/strong>: Clinician\n\n<strong>Flow<\/strong>:\n<ol>\n \t<li>Clinician authenticates using smart card.<\/li>\n \t<li>Software confirms user credentials and permissions for specific machine.<\/li>\n \t<li>Software logs access.<\/li>\n \t<li>Software displays patient search.<\/li>\n \t<li>Clinician selects \u201cAdvanced Patient Search.\u201d<\/li>\n \t<li>Software confirms user access permissions for advanced search page.<\/li>\n \t<li>Clinician selects ailment and patient status.<\/li>\n \t<li>Clinician executes search using \u201cSearch\u201d button.<\/li>\n \t<li>Software returns results.<\/li>\n \t<li>Software logs query.<\/li>\n<\/ol>\n<\/div>\n<\/div>\n<p class=\"captionstyle\"><strong>Figure 3.2\u00a0<\/strong>Simple Use Case<\/p>\n\n<h2>3.6.1 User Stories<\/h2>\nUser stories are a method for specifying functional requirements. They describe a small piece of the software\u2019s functionality in a simple and easy-to-read sentence. They are written in plain English so that nontechnical people (e.g., users, clients, other stakeholders) can understand them.\n<div class=\"textbox\"><strong>The body of a user story is commonly written using this format<\/strong>\nAs a &lt;ROLE&gt;, I want &lt;SOME FUNCTIONALITY&gt; so that I get &lt;SOME BENEFIT&gt;<\/div>\n<p class=\"page-break-after\">User stories can be written on 3 \u00d7 5 index cards and then stuck on a wall or whiteboard. They can also be typed into task and project management systems (e.g., Jira, Asana, and the like). Figure 3.3 provides a few examples of user stories within the context of a project (they have priorities and other project-related information attached to them).<\/p>\n<div class=\"boxcontainer\">\n<div class=\"textbox textbox--sidebar left boxfigure\">\n\nUS-023: Disabling Comments\nPriority: Highest (8)\nSprint: 2\nAssigned to: Emrah Tuukka\n\nAs an admin, I want to disable comments so that I can control spam and spread of disinformation.\n\n<\/div>\n<div class=\"textbox textbox--sidebar left boxfigure\">\n\nUS-034: Personalized Avatar Background\nPriority: Lowest (1)\nSprint: 3\nAssigned to: Ade Einarr\n\nAs a registered user, I want to change the background around my face on my avatar so that I can personalize my experience.\n\n<\/div>\n<div class=\"textbox textbox--sidebar left boxfigure\">\n\nUS-012: App Purpose\nPriority: Highest (8)\nSprint: 1\nAssigned to: Randomira Philibert\n\nAs a new user, I want to read about what features the app provides so that I can decide whether to use it.\n\n<\/div>\n<\/div>\n<p class=\"captionstyle\"><strong>Figure 3.3\u00a0<\/strong>User Story Functional Requirement Examples<\/p>\nWant more examples of user stories? Mountain Goat Software provides <a href=\"https:\/\/www.mountaingoatsoftware.com\/uploads\/documents\/example-user-stories.pdf\">200 example user stories [PDF]<\/a> (Cohn, <span class=\"citation\">[pb_glossary id=\"650\"]2004[\/pb_glossary]<\/span>). They list only the \u201cAs a . . .\u201d part of the user story requirement.\n\nAnyone on the team\u2014or any project stakeholder\u2014might come up with user stories. Once the user stories are initially defined, they can be used to start a conversation with the client and others on the team. Clients can guide you on setting priorities for user stories. This conversation is also a good time to get more details about the user stories, which should be added to the card.\n<div class=\"textbox textbox--sidebar\"><strong>Want examples of comically bad user stories? <\/strong>Check out the <a href=\"https:\/\/twitter.com\/shituserstory\">Shit User Story<\/a> Twitter feed (<span class=\"citation\">[pb_glossary id=\"657\"]@ShitUserStory[\/pb_glossary]<\/span>)<\/div>\nWhat makes a good user story? Besides the characteristics of good requirements listed earlier in this chapter, the <em>[pb_glossary id=\"854\"]INVEST[\/pb_glossary]<\/em> acronym (Wake, <span class=\"citation\">[pb_glossary id=\"662\"]2003[\/pb_glossary]<\/span>) can help you remember characteristics of good user stories:\n<ul>\n \t<li>(I) <strong>Independent<\/strong>: Does not have unnecessary dependencies or overlap with other user stories.\n<ul>\n \t<li>Two user stories that overlap:\n<ul>\n \t<li>\u201cAs a new user, I want to register so that . . .\u201d<\/li>\n \t<li>\u201cAs a new user, I want to register using my Google account so that . . .\u201d<\/li>\n<\/ul>\n<\/li>\n \t<li>Set of user stories that don\u2019t overlap (but some user stories need to be completed before others\u2014that\u2019s ok):\n<ul>\n \t<li>\u201cAs a new user, I want to view the registration page so that . . .\u201d<\/li>\n \t<li>\u201cAs a new user, I want to register using Facebook so that . . .\u201d<\/li>\n \t<li>\u201cAs a new user, I want to register using Google so that . . .\u201d<\/li>\n \t<li>\u201cAs a new user, I want my registration details to be stored so that . . .\u201d<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<ul>\n \t<li>(N) <strong>Negotiable<\/strong>: Encourages instead of discourages discussion and gives developers flexibility.\n<ul>\n \t<li>Does not encourage discussion: \u201cAs a logged in user, I want to choose either black or white so that . . .\u201d<\/li>\n \t<li>Encourages discussion: \u201cAs a logged in user, I want to choose from multiple colors so that . . .\u201d<\/li>\n<\/ul>\n<\/li>\n \t<li>(V) <strong>Valuable<\/strong>: Fulfills a user need.\n<ul>\n \t<li>Does not fulfill a user need: \u201cAs an Enterprise user, I want to watch a little race car drive around the screen so that I can do something fun while requesting API end points.\u201d<\/li>\n \t<li>Fulfills a user need: \u201cAs an Enterprise user, I want to import my API end point requests so that my requests take less time and are less tedious.\u201d<\/li>\n<\/ul>\n<\/li>\n \t<li>(E) <strong>Estimable<\/strong>: Can be given a time estimate.\n<ul>\n \t<li>Difficult to give a time estimate: \u201cAs a new user, I want enough encouragement to register so that I\u2019ll register.\u201d<\/li>\n \t<li>Easier to estimate: \u201cAs a new user, I want to compare plan pricing so that I can decide which plan to choose.\u201d<\/li>\n<\/ul>\n<\/li>\n \t<li>(S) <strong>Small<\/strong>: Can fit into a single development period (e.g., a two-week Sprint)\n<ul>\n \t<li>Probably too large for a Sprint: \u201cAs a user, I want to play chess on my phone so that I have something to do while waiting at the pharmacy.\u201d<\/li>\n \t<li>Smaller: \u201cAs a user, I want to move my pawn so that I can take my turn in chess.\u201d<\/li>\n<\/ul>\n<\/li>\n \t<li>(T) <strong>Testable<\/strong>: Possible to determine it\u2019s done.\n<ul>\n \t<li>Difficult to determine whether it\u2019s done: \u201cAs a guest user, I want to be satisfied with my experience so that I will want to sign up.\u201d<\/li>\n \t<li>Less difficult: \u201cAs a guest user, I want to try out the AI text generator without registering first so that I can decide whether to subscribe.\u201d<\/li>\n<\/ul>\n<\/li>\n<\/ul>\nThere is some overlap between INVEST and the general characteristics of good requirements mentioned above (which is comforting), but you might find that INVEST is easier to remember.\n\nHow do you know when a user story is done? This is negotiated with the client and added to the user story as acceptance criteria. Acceptance criteria say what must be true about the functionality specified by the user story for the user story to be considered done (i.e., establishing the [pb_glossary id=\"855\"]Definition of Done[\/pb_glossary] for the user story). Figure 3.4 adds a DoD to one of the user stories from Figure 3.3. The DoD is composed of acceptance criteria following the given-when-then format.\n<div class=\"boxcontainer\">\n<div class=\"textbox textbox--sidebar left boxfigure\">\n\nUS-023: Disabling Comments\nPriority: Highest (8)\nSprint: 2\nAssigned to: Emrah Tuukka\n\nAs an admin, I want to disable comments so that I can control spam and the spread of disinformation.\n\n<strong>Definition of Done<\/strong>\n<ul>\n \t<li>Given the user is logged in as a user, when they navigate to \u201cSettings,\u201d then there is a \u201cDisable Comments\u201d button.<\/li>\n \t<li>Given the user is on the \u201cSettings\u201d page, when they activate \u201cDisable Comments,\u201d then a status message appears that indicates the action was successful. The message appears within 10 milliseconds.<\/li>\n \t<li>Given the user has activated \u201cDisable Comments,\u201d when they navigate to a \u201cPost\u201d page, then \u201cComments disabled\u201d appears in the \u201cComments\u201d section, and no comments are showing.<\/li>\n<\/ul>\n<\/div>\n<p class=\"captionstyle\"><strong>Figure 3.4\u00a0<\/strong>User Story with Definitions of Done Example<\/p>\nOnce each of the acceptance criteria are confirmed to be done, the user story can be considered \u201cDONE-done.\u201d\n\nIdeally, testing the acceptance criteria can be automated. Figure 3.5 provides example [pb_glossary id=\"856\"]pseudocode[\/pb_glossary] for testing an acceptance criterion.\n<div style=\"margin-top: 1em;\">\n<ol class=\"codestyle nolist\">\n \t<li><code><span class=\"red\">def<\/span> test_go_to_time():<\/code><\/li>\n \t<li><code>\u00a0\u00a0<span class=\"green\"># given<\/span><\/code><\/li>\n \t<li><code>\u00a0\u00a0assert os.isWindows(),<span class=\"blue\">\"Not Windows!\"<\/span><\/code><\/li>\n \t<li><code>\u00a0\u00a0player.<span class=\"red\">open<\/span>()<\/code><\/li>\n \t<li><code>\u00a0\u00a0player.play_video(<span class=\"blue\">'test.mkv'<\/span>)<\/code><\/li>\n \t<li><code><\/code><\/li>\n \t<li><code>\u00a0\u00a0<span class=\"green\"># when<\/span><\/code><\/li>\n \t<li><code>\u00a0\u00a0user.send_keyboard_shortcut(<span class=\"blue\">\"Ctrl-T\"<\/span>)<\/code><\/li>\n \t<li><code><\/code><\/li>\n \t<li><code>\u00a0\u00a0<span class=\"green\"># then<\/span><\/code><\/li>\n \t<li><code>\u00a0\u00a0assert player.screen.is_showing(GOTOTIME)<\/code><\/li>\n<\/ol>\n<p class=\"captionstyle\"><strong>Figure 3.5\u00a0<\/strong>Pseudocode for Testing an Example Acceptance Criterion<\/p>\n\n<\/div>\n<\/div>\n<h2>3.6.2 Use Cases<\/h2>\nUse cases are a more formal method of specifying functional requirements. They are structured descriptions of what a system is required to do when a user interacts. Figure 3.2 showed a simple use case example, and additional examples can be found in the <a href=\"https:\/\/s3.amazonaws.com\/digitalgov\/_legacy-img\/2014\/01\/Marsh-Personas.pdf\">Digital.gov Usability Starter Kit PDF about use cases and personas<\/a> (US General Services Administration, <span class=\"citation\">[pb_glossary id=\"661\"]2014[\/pb_glossary]<\/span>).\n\nAs use cases are less common in Agile, the remainder of this section will provide only a summary of how use cases are structured.\n<h3>Required Parts of a Use Case<\/h3>\nEvery use case has the following.\n<ul>\n \t<li><strong>Name<\/strong>: A short title for the use case that often starts with a verb (e.g., \u201cSchedule weekly wellness check\u201d). The name briefly states the user objective the use case will describe.<\/li>\n \t<li><strong>Actor(s)<\/strong>: The user or users (human\/nonhuman\/computer) that are interacting with the software (e.g., \u201cMedical staff\u201d).<\/li>\n \t<li><strong>Flow of events<\/strong>: Sequence of actions describing the interaction between the actor and the software (a.k.a. \u201cbasic course of action\u201d or \u201csuccess scenario\u201d).<\/li>\n<\/ul>\nSometimes, the actor is implied through the flow of events (e.g., \u201cShopper selects the calendar icon\u201d). Other times, the actor is stated separately from the flow of events (e.g., \u201cActor: Shopper\u201d).\n<h3>Additional Parts of a Use Case<\/h3>\nThe following are sometimes included in use cases.\n<ul>\n \t<li><strong>Identifier<\/strong>: A unique way of referring to the use case (e.g., UC-002).<\/li>\n \t<li><strong>Preconditions<\/strong>: What must be true before the flow (e.g., \u201cThe shopper has added at least one product to their shopping cart\u201d).<\/li>\n \t<li><strong>Postconditions<\/strong>: What must be true after the flow (e.g., \u201cThe shopper received an order confirmation email\u201d).<\/li>\n \t<li><strong>Business relevance<\/strong>: Justification for why the use case exists.<\/li>\n \t<li><strong>Dependencies<\/strong>: Other use cases the use case relies on. The unique identifier is handy for this part.<\/li>\n \t<li><strong>Extensions<\/strong>: Contingencies, alternate routes, and branches to other use cases.<\/li>\n \t<li><strong>Priorities<\/strong>: The importance of the use case.<\/li>\n \t<li><strong>Nonfunctional requirements<\/strong>: How well the software must perform during the flow.<\/li>\n<\/ul>\n<h1>3.7 Requirements Specification<\/h1>\nThe process of writing down requirements is called [pb_glossary id=\"857\"]requirements specification[\/pb_glossary]. Used as a noun, requirements specification refers to the document that contains the requirements. That document may also be a [pb_glossary id=\"858\"]software requirements specification (SRS)[\/pb_glossary]. The best way to learn about SRSs is to look at some.\n<div class=\"textbox textbox--sidebar\">Another type of software document, which is sometimes confused with an SRS, is a software design document (SDD). If the SRS is what the software should be, the SDD is what the software is. There is often overlap between these two documents.<\/div>\n<strong>Freely available SRS examples<\/strong> (including some for open source software):\n<ul>\n \t<li><a href=\"https:\/\/nvlpubs.nist.gov\/nistpubs\/ams\/NIST.AMS.300-2.pdf\">SRS for apps and a data repository for distributing manufacturing data [PDF]<\/a> (Hedberg et al., <span class=\"citation\">[pb_glossary id=\"653\"]2017[\/pb_glossary]<\/span>).<\/li>\n \t<li><a href=\"https:\/\/www.nrcs.usda.gov\/publications\/ceap-watershed-2006-stewards-design.pdf\">SRS for data system that assesses conservation practices [PDF]<\/a> (CEAP, <span class=\"citation\">[pb_glossary id=\"649\"]2006[\/pb_glossary]<\/span>).<\/li>\n \t<li><a href=\"http:\/\/selab.netlab.uky.edu\/~ashlee\/cs617\/project2\/PDFSam.pdf\">SRS for an app that splits and merges PDFs [PDF]<\/a> (Spyridonos, <span class=\"citation\">[pb_glossary id=\"659\"]2010[\/pb_glossary]<\/span>).<\/li>\n \t<li><a href=\"http:\/\/openvibe.inria.fr\/openvibe\/wp-content\/uploads\/2018\/04\/CERT-Software-Requirement-Specification.pdf\">SRS for software that processes electroencephalography data [PDF]<\/a> (OpenVIBE, <span class=\"citation\">[pb_glossary id=\"656\"]2018[\/pb_glossary]<\/span>).<\/li>\n \t<li><a href=\"https:\/\/vyasa.sourceforge.net\/vyasa_software_requirements_specification.pdf\">SRS for library software [PDF]<\/a> (Eaker, <span class=\"citation\">[pb_glossary id=\"651\"]2006[\/pb_glossary]<\/span>).<\/li>\n<\/ul>\nIf any links are broken, try the <a href=\"https:\/\/web.archive.org\/\">Wayback Machine<\/a>.\n<h1>3.8 Summary<\/h1>\nThere are two main types of software requirements: functional and nonfunctional.\n\nA functional requirement is \u201ca description of a behavior that a system will exhibit under specific conditions\u201d (Wiegers &amp; Beatty, 2013, p. 599). There are different formats for writing functional requirements such as the given-when-then format, user stories, and use cases. User stories are used in Agile software development. The given-when-then format is used for writing user story acceptance criteria. A set of acceptance criteria is used to determine whether a user story has been completed (Definition of Done).\n\nA nonfunctional requirement is \u201ca description of a property or characteristic that a system must exhibit or a constraint that it must respect\u201d (Wiegers &amp; Beatty, 2013, p. 600). Quality attributes are words for describing \u201ca service or performance characteristic of software\u201d (Wiegers &amp; Beatty, 2013, p. 601).\n\nThere are standards for what makes a good requirement, such as being correct, unambiguous, complete, consistent, ranked for importance and\/or stability, verifiable, modifiable, and traceable. INVEST is an acronym for remembering standards for good user stories: independent, negotiable, valuable, estimable, small, and testable.\n\nAn SRS can contain both nonfunctional and functional requirements.\n<h1>References<\/h1>\n<p class=\"hanging-indent\">Agile Alliance. (n.d.). <em>What is \u201cgiven - when - then\u201d?<\/em> https:\/\/www.agilealliance.org\/glossary\/gwt\/<\/p>\n<p class=\"hanging-indent\">CEAP. Conservation Effects Assessment Project. (2006). <em>System requirements specification for STEWARDS. <\/em>US Department of Agriculture, Agricultural Research Service. <a href=\"https:\/\/www.nrcs.usda.gov\/publications\/ceap-watershed-2006-stewards-design.pdf\">https:\/\/www.nrcs.usda.gov\/publications\/ceap-watershed-2006-stewards-design.pdf<\/a><\/p>\n<p class=\"hanging-indent\">Cohn, M. (2004). <em>Example user stories<\/em>. Mountain Goat Software. <a href=\"https:\/\/www.mountaingoatsoftware.com\/uploads\/documents\/example-user-stories.pdf\">https:\/\/www.mountaingoatsoftware.com\/uploads\/documents\/example-user-stories.pdf<\/a><\/p>\n<p class=\"hanging-indent\">Eaker, F. (2006, November). <em>Software requirements specification<\/em>. Vyasa. <a href=\"https:\/\/vyasa.sourceforge.net\/vyasa_software_requirements_specification.pdf\">https:\/\/vyasa.sourceforge.net\/vyasa_software_requirements_specification.pdf<\/a><\/p>\n<p class=\"hanging-indent\">Hanington, B. M., &amp; Martin, B. (2019). <em>Universal Methods of Design: 125 ways to research complex problems, develop innovative ideas, and design effective solutions<\/em>. Rockport Publishers.<\/p>\n<p class=\"hanging-indent\">Hedberg, T., Helu, M., &amp; Newrock, M. (2017, December). <em>Software requirements specification to distribute manufacturing data<\/em>. NIST Advanced Manufacturing Series 300-2. National Institute of Standards and Technology. <a href=\"https:\/\/nvlpubs.nist.gov\/nistpubs\/ams\/NIST.AMS.300-2.pdf\">https:\/\/nvlpubs.nist.gov\/nistpubs\/ams\/NIST.AMS.300-2.pdf<\/a><\/p>\n<p class=\"hanging-indent\">OpenVIBE. (2018, April). <em>Inria Innovation Lab Certivibe v 1.0 software requirement specification<\/em>. <a href=\"http:\/\/openvibe.inria.fr\/openvibe\/wp-content\/uploads\/2018\/04\/CERT-Software-Requirement-Specification.pdf\">http:\/\/openvibe.inria.fr\/openvibe\/wp-content\/uploads\/2018\/04\/CERT-Software-Requirement-Specification.pdf<\/a><\/p>\n<p class=\"hanging-indent\">@ShitUserStory. (n.d.). <em>Shit User Story<\/em>. Twitter. <a href=\"https:\/\/twitter.com\/shituserstory\">https:\/\/twitter.com\/shituserstory<\/a><\/p>\n<p class=\"hanging-indent\">Spyridonos, P. (2010, February 6). <em>Software requirements specification for PDF split and merge requirements for version 2.1.0<\/em>. University of Kentucky Software Verification and Validation Lab. <a href=\"https:\/\/selab.netlab.uky.edu\/~ashlee\/cs617\/project2\/PDFSam.pdf\">https:\/\/selab.netlab.uky.edu\/~ashlee\/cs617\/project2\/PDFSam.pdf<\/a><\/p>\n<p class=\"hanging-indent\">\u00a0Texas Department of Information Resources. (2008, January 14). <em>Software requirements specification instructions<\/em>. <a href=\"https:\/\/dir.texas.gov\/sites\/default\/files\/Requirements%20Traceability%20Matrix%20Instructions.pdf\">https:\/\/dir.texas.gov\/sites\/default\/files\/Requirements%20Traceability%20Matrix%20Instructions.pdf<\/a><\/p>\n<p class=\"hanging-indent\">US General Services Administration. (2014, January). <em>USDA personas and use cases<\/em>. <a href=\"https:\/\/s3.amazonaws.com\/digitalgov\/_legacy-img\/2014\/01\/Marsh-Personas.pdf\">https:\/\/s3.amazonaws.com\/digitalgov\/_legacy-img\/2014\/01\/Marsh-Personas.pdf<\/a><\/p>\n<p class=\"hanging-indent\">Wake, B. (2003, August 17). <em>Invest in good stories, and Smart Tasks<\/em>. XP123 Exploring Extreme Programming. <a href=\"https:\/\/xp123.com\/articles\/invest-in-good-stories-and-smart-tasks\/\">https:\/\/xp123.com\/articles\/invest-in-good-stories-and-smart-tasks\/<\/a><\/p>\n<p class=\"hanging-indent\">Wiegers, K., &amp; Beatty, J. (2013). <em>Software requirements<\/em> (3rd ed.). Developer Best Practices Series. Microsoft Press.<\/p>\n<p class=\"hanging-indent\">Wikimedia Foundation. (2023, March 23). <em>List of system quality attributes<\/em>. <a href=\"https:\/\/en.wikipedia.org\/wiki\/List_of_system_quality_attributes\">https:\/\/en.wikipedia.org\/wiki\/List_of_system_quality_attributes<\/a><\/p>","rendered":"<div class=\"imgbleed\"><a href=\"https:\/\/open.oregonstate.education\/app\/uploads\/sites\/174\/2023\/09\/CoverChapter04.png\"><img decoding=\"async\" class=\"aligncenter size-full wp-image-29\" src=\"https:\/\/libraryresources.nse.org.ng\/wp-content\/uploads\/sites\/16\/2023\/09\/CoverChapter04.png\" alt=\"Chapter cover\" width=\"2550\" height=\"1320\" srcset=\"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2023\/09\/CoverChapter04.png 2550w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2023\/09\/CoverChapter04-300x155.png 300w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2023\/09\/CoverChapter04-1024x530.png 1024w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2023\/09\/CoverChapter04-768x398.png 768w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2023\/09\/CoverChapter04-1536x795.png 1536w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2023\/09\/CoverChapter04-2048x1060.png 2048w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2023\/09\/CoverChapter04-65x34.png 65w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2023\/09\/CoverChapter04-225x116.png 225w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2023\/09\/CoverChapter04-350x181.png 350w\" sizes=\"(max-width: 2550px) 100vw, 2550px\" \/><\/a><\/div>\n<h2 class=\"chtitle\">Chapter 3<br \/>\nRequirements<\/h2>\n<p>A software requirement is a rule the software must conform to: what it must do, how well, and within what constraints or limits.<\/p>\n<h1>3.1 Types of Requirements<\/h1>\n<p>There are two main <strong>types of requirements<\/strong>:<\/p>\n<ol>\n<li>Functional requirements are \u201cA description of a behavior that a system will exhibit under specific conditions\u201d (Wiegers &amp; Beatty, <span class=\"citation\">2013<\/span>, p. 599). For example, \u201cIf the user activates the \u2018log in\u2019 button, the login page will appear.\u201d Functional requirements answer the question, \u201cWhat must the software do?\u201d<\/li>\n<li>Nonfunctional requirements are \u201cA description of a property or characteristic that a system must exhibit or a constraint that it must respect\u201d (Wiegers &amp; Beatty, 2013, p. 600). For example, \u201cIf the user activates the \u2018log in\u2019 button, the login page will appear within 500 milliseconds.\u201d This nonfunctional requirement has a characteristic that the system must exhibit: responsiveness. Responsiveness is also called a quality attribute. An example of a nonfunctional requirement about respecting a constraint is, \u201cThe GUI toolkit must be able to display non-rectangular windows.\u201d<\/li>\n<\/ol>\n<p>Figure 3.1 shows a simple example of a design failing to reflect a nonfunctional requirement and a functional requirement.<\/p>\n<div class=\"largeimg\">\n<figure id=\"attachment_101\" aria-describedby=\"caption-attachment-101\" style=\"width: 2279px\" class=\"wp-caption aligncenter\"><a href=\"https:\/\/open.oregonstate.education\/app\/uploads\/sites\/174\/2023\/09\/Fig04.01.png\"><img decoding=\"async\" class=\"size-full wp-image-30\" src=\"https:\/\/libraryresources.nse.org.ng\/wp-content\/uploads\/sites\/16\/2026\/03\/Fig04.01.png\" alt=\"Sketch of house\" width=\"2279\" height=\"1721\" srcset=\"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2026\/03\/Fig04.01.png 2279w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2026\/03\/Fig04.01-300x227.png 300w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2026\/03\/Fig04.01-1024x773.png 1024w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2026\/03\/Fig04.01-768x580.png 768w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2026\/03\/Fig04.01-1536x1160.png 1536w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2026\/03\/Fig04.01-2048x1547.png 2048w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2026\/03\/Fig04.01-65x49.png 65w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2026\/03\/Fig04.01-225x170.png 225w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2026\/03\/Fig04.01-350x264.png 350w\" sizes=\"(max-width: 2279px) 100vw, 2279px\" \/><\/a><figcaption id=\"caption-attachment-101\" class=\"wp-caption-text\"><strong>Figure 3.1<\/strong> Two Failed Requirements<\/figcaption><\/figure>\n<\/div>\n<p><em>Note.<\/em> This rolling table fails the nonfunctional requirement of fitting through an average door and the functional requirement of having four legs.<\/p>\n<h1>3.2 Why Requirements Matter<\/h1>\n<p>The design and implementation of software should, ideally, follow from the requirements. Here are some <strong>ways requirements are helpful<\/strong> and reasons they are important:<\/p>\n<ul>\n<li>When developers aren\u2019t given requirements, they <strong>might prioritize functionality they personally think is important or fun<\/strong> to implement, but what developers want to implement might not make the project successful.<\/li>\n<li>When multiple developers are working on the same code, requirements can <strong>help them stay in sync<\/strong> and <strong>pursue the same goal<\/strong>. Without requirements, time, effort, and money can be wasted implementing conflicting code.<\/li>\n<li>When requirements aren\u2019t specified, it\u2019s easier for project stakeholders (e.g., clients, partners, investors, consultants, management) to <strong>influence the project toward satisfying their own<\/strong> (possibly fleeting) <strong>wants or needs<\/strong>. This can result in the project drifting away from what it was originally intended to do\u2014and can lead to project failure.<\/li>\n<li>Requirements are <strong>helpful for communicating<\/strong> about software with stakeholders, <strong>keeping track<\/strong> of everything that needs to get done, and helping you and the client <strong>decide what really needs to get done<\/strong> (clients sometimes don\u2019t know what they really need).<\/li>\n<\/ul>\n<h1>3.3 What Makes a Good Requirement<\/h1>\n<p>Teams or organizations can choose their own standards for what makes a good requirement. Here is <strong>one set of standards<\/strong> (Texas Department of Information Resources, <span class=\"citation\">2008<\/span>):<\/p>\n<p><strong>Requirements should be<\/strong> . . .<\/p>\n<ul>\n<li><strong>Correct<\/strong>: What they say is right.<\/li>\n<li><strong>Unambiguous<\/strong>: There is only one way to interpret them.<\/li>\n<li><strong>Complete<\/strong>: They cover all that\u2019s important.<\/li>\n<li><strong>Consistent<\/strong>: They aren\u2019t contradictory.<\/li>\n<li><strong>Ranked for importance and\/or stability<\/strong>.<\/li>\n<li><strong>Verifiable<\/strong> <strong>or testable<\/strong>: There\u2019s a way to figure out if they\u2019re satisfied.<\/li>\n<li><strong>Modifiable<\/strong>: They can be changed.<\/li>\n<li><strong>Traceable<\/strong>: It\u2019s possible to figure out where they came from.<\/li>\n<\/ul>\n<p>Requirements should also be . . .<\/p>\n<ul>\n<li><strong>Cross-referenced to earlier documents<\/strong> that relate.<\/li>\n<li><strong>Uniquely identifiable<\/strong>.<\/li>\n<li><strong>Organized for maximum readability.<\/strong><\/li>\n<\/ul>\n<h1>3.4 Requirements Elicitation<\/h1>\n<p class=\"page-break-after\">The process of gathering requirements is called requirements elicitation. Requirements can come from any stakeholder, including clients, managers, users, governments, developers of software to be integrated with yours, the development team, and yourself. Requirements elicitation involves both detecting stakeholders\u2019 wants and needs and using your professional judgment to decide which requirements to focus on.<\/p>\n<p><strong>To detect stakeholders\u2019 wants and needs<\/strong>, communicate and observe. Some methods:<\/p>\n<ul>\n<li><strong>Interviews<\/strong>: Structured (questions defined ahead of time), semi-structured (some questions predefined, some generated during interview), or unstructured conversations.<\/li>\n<li><strong>Focus groups<\/strong>: Small, group conversations in which the participants discuss topics among themselves, with moderator guidance.<\/li>\n<li><strong>Lab studies<\/strong>: Participants perform tasks in a controlled setting (e.g., try to use an early prototype, then give feedback).<\/li>\n<li><strong>Exploratory research<\/strong>: Multiple methods of immersing oneself within the world of relevant people and products, with the purpose of gaining knowledge and developing empathy for stakeholders. For example, after doing a fly-on-the-wall observation, you realize that people can\u2019t find Aisle 25 because it\u2019s in an unexpected place. You decide to prioritize the Aisle Map feature in the store\u2019s app.<\/li>\n<\/ul>\n<p>Depending on the software development environment, <strong>these methods might be the jurisdiction of specialist researchers in marketing or interaction design<\/strong>. Hanington and Martin (<span class=\"citation\">2019<\/span>) describe these specialist methods (and many other relevant methods) in more detail.<\/p>\n<p><strong>Developers can elicit requirements, too<\/strong>, by having conversations with stakeholders. There are <strong>factors that can affect the success <\/strong>of that approach, however.<\/p>\n<ul>\n<li><strong>Stakeholders might not have experience or expertise<\/strong>. Developers can help bridge the gap between what the stakeholder wants and what is technically feasible and reasonable (e.g., given time, cost, and scope, what is also known as the triple constraint).<\/li>\n<li><strong>Stakeholders might not have good ideas<\/strong>. They might be incorrect about what they or other people want or will use. Developers can sometimes provide guidance toward better ideas, but developers can also have bad ideas. Methods such as focus groups, usability testing, and releasing a minimum viable product (MVP) can help with figuring out whether users will use (and pay for) the software.<\/li>\n<li><strong>Stakeholders might not know what they want<\/strong>. They may have a rough idea, or an idea that\u2019s at odds with their wants or needs.<\/li>\n<li><strong>Stakeholders might want what\u2019s bad for them or others<\/strong>. For example, users want apps that make their face beautiful in photos, such features may promote unrealistic beauty standards.<\/li>\n<li><strong>Stakeholders are humans<\/strong>. They communicate imperfectly.<\/li>\n<\/ul>\n<p>With experience, you can learn how to effectively gather relevant information from stakeholders and make your own judgments about how that information translates into requirements.<\/p>\n<h1>3.5 Nonfunctional Requirements<\/h1>\n<p>Nonfunctional requirements describe how well the software needs to perform or what constraints it must respect.<\/p>\n<p><strong>Examples of nonfunctional requirements<\/strong>:<\/p>\n<ul>\n<li>Response time should be a few seconds or less in all operating environments.<\/li>\n<li>The front-end design must be evaluated using the Inclusivity Heuristics by at least two people each Sprint.<\/li>\n<li>The software must be available 24 hours a day, seven days a week, and must have an uptime of 99.99%.<\/li>\n<\/ul>\n<p>Notice that <strong>each nonfunctional requirement has a quantity<\/strong>. That helps make it testable (a criterion for a good requirement).<\/p>\n<h2>3.5.1 Quality Attributes<\/h2>\n<div class=\"textbox textbox--sidebar\">There is a long list of quality attributes on Wikipedia\u2019s \u201c<a href=\"https:\/\/en.wikipedia.org\/wiki\/List_of_system_quality_attributes\">List of system quality attributes<\/a>\u201d page (Wikimedia Foundation, <span class=\"citation\">2023<\/span>).<\/div>\n<p>Quality attributes are words for describing \u201ca service or performance characteristic of software\u201d (Wiegers &amp; Beatty, 2013, p. 601). <strong>Some common quality attributes <\/strong>are as follows.<\/p>\n<ul>\n<li><strong>Maintainability<\/strong>: Amount of effort needed for developers to update, refactor, or otherwise modify the software\u2019s code.<\/li>\n<li><strong>Portability<\/strong>: Amount of effort needed to run the software on different platforms.<\/li>\n<li><strong>Reliability<\/strong>: How often the software\u2019s functions succeed or fail.<\/li>\n<li><strong>Efficiency<\/strong>: Number of resources the software requires.<\/li>\n<li><strong>Integrity<\/strong>: How frequently the software loses data.<\/li>\n<li><strong>Memorability<\/strong>: Amount of time users must spend relearning functionality.<\/li>\n<li><strong>Flexibility<\/strong>: Number of different ways the software can be used.<\/li>\n<li><strong>Interoperability<\/strong>: Ease with which the software can integrate with other software.<\/li>\n<li><strong>Reusability<\/strong>: Extent to which the code can easily be used to solve other problems.<\/li>\n<\/ul>\n<p>Each quality attribute can be converted to a scale. For example, the lowest value on a reliability scale for a single could be \u201cthe function succeeds 0% of the time,\u201d and 100% would of course be the opposite pole. Given this scale, we can specify a nonfunctional requirement by defining a performance threshold:<\/p>\n<ul>\n<li>The function must have high reliability (succeeds &gt;99% of the time).<\/li>\n<\/ul>\n<p>When you select quality attributes for your software, you are prioritizing what qualities matter most to you\/your team\/the project. Ideally, your team would keep these quality attributes (and the corresponding nonfunctional requirements) in mind for the duration of the project. If the software is not meeting the nonfunctional requirements, either the software or the threshold of acceptability needs to change.<\/p>\n<h2>3.5.2 Constraints<\/h2>\n<p>Some nonfunctional requirements are not about quality attributes and are instead about staying within constraints. The following are <strong>example types of constraints<\/strong> (Wiegers &amp; Beatty, 2013):<\/p>\n<ul>\n<li>Those limiting technology choices (programming languages, frameworks, databases, application programming interface (API) types, etc.).<\/li>\n<li>Those limiting what platforms are targeted (e.g., mobile versus desktop, iOS versus Android).<\/li>\n<li>Those limiting what about the software can change (e.g., for backward compatibility).<\/li>\n<li>Those limiting how code can be written (e.g., following particular coding and documentation standards).<\/li>\n<li>Those limiting how data can be handled (e.g., must only be stored on US servers).<\/li>\n<\/ul>\n<p>A conceptual difference between constraints and quality attributes is that constraints are often externally mandated, while quality attributes can be chosen internally by the team.<\/p>\n<h1>3.6 Functional Requirements<\/h1>\n<p>Functional requirements described what the software must do.<\/p>\n<p><strong>Example functional requirements<\/strong>:<\/p>\n<ul>\n<li>When the \u201cregister\u201d button is activated, the user\u2019s information is added to the database and a \u201cthank you for registering\u201d screen displays.<\/li>\n<li>As a wholesaler, I want to see the wholesale and retail prices when I go to \u201cproduct view\u201d so that I know how much money I\u2019m going to make.<\/li>\n<li>Given a user has performed at least one editing action, when they activate the \u201caction history\u201d window, they see a list of editing actions they have taken.<\/li>\n<\/ul>\n<p>Each of these functional requirements is formatted differently. There isn\u2019t a name for the first format; it simply states what should happen when a particular action is taken in the software. The second uses user story format, which is common in Agile software development. This format emphasizes the user, what the user is trying to do, and their motivations. The third requirement uses the given-when-then format (see <span class=\"citation\">Agile Alliance <\/span>for more information), which incorporates context. This format is commonly used to write user story acceptance criteria: a set of statements that, when true, indicate that the user story has been completed.<\/p>\n<p class=\"page-break-after\"><strong>A more formal way to write functional requirements<\/strong> is the use case format, which follows a template. Figure 3.2 contains an <strong>example use case using a simple template<\/strong>.<\/p>\n<div class=\"boxcontainer\">\n<div class=\"textbox textbox--sidebar left boxfigure\">\n<p><strong>Name<\/strong>: Generate list of recovered patients<\/p>\n<p><strong>Actor<\/strong>: Clinician<\/p>\n<p><strong>Flow<\/strong>:<\/p>\n<ol>\n<li>Clinician authenticates using smart card.<\/li>\n<li>Software confirms user credentials and permissions for specific machine.<\/li>\n<li>Software logs access.<\/li>\n<li>Software displays patient search.<\/li>\n<li>Clinician selects \u201cAdvanced Patient Search.\u201d<\/li>\n<li>Software confirms user access permissions for advanced search page.<\/li>\n<li>Clinician selects ailment and patient status.<\/li>\n<li>Clinician executes search using \u201cSearch\u201d button.<\/li>\n<li>Software returns results.<\/li>\n<li>Software logs query.<\/li>\n<\/ol>\n<\/div>\n<\/div>\n<p class=\"captionstyle\"><strong>Figure 3.2\u00a0<\/strong>Simple Use Case<\/p>\n<h2>3.6.1 User Stories<\/h2>\n<p>User stories are a method for specifying functional requirements. They describe a small piece of the software\u2019s functionality in a simple and easy-to-read sentence. They are written in plain English so that nontechnical people (e.g., users, clients, other stakeholders) can understand them.<\/p>\n<div class=\"textbox\"><strong>The body of a user story is commonly written using this format<\/strong><br \/>\nAs a &lt;ROLE&gt;, I want &lt;SOME FUNCTIONALITY&gt; so that I get &lt;SOME BENEFIT&gt;<\/div>\n<p class=\"page-break-after\">User stories can be written on 3 \u00d7 5 index cards and then stuck on a wall or whiteboard. They can also be typed into task and project management systems (e.g., Jira, Asana, and the like). Figure 3.3 provides a few examples of user stories within the context of a project (they have priorities and other project-related information attached to them).<\/p>\n<div class=\"boxcontainer\">\n<div class=\"textbox textbox--sidebar left boxfigure\">\n<p>US-023: Disabling Comments<br \/>\nPriority: Highest (8)<br \/>\nSprint: 2<br \/>\nAssigned to: Emrah Tuukka<\/p>\n<p>As an admin, I want to disable comments so that I can control spam and spread of disinformation.<\/p>\n<\/div>\n<div class=\"textbox textbox--sidebar left boxfigure\">\n<p>US-034: Personalized Avatar Background<br \/>\nPriority: Lowest (1)<br \/>\nSprint: 3<br \/>\nAssigned to: Ade Einarr<\/p>\n<p>As a registered user, I want to change the background around my face on my avatar so that I can personalize my experience.<\/p>\n<\/div>\n<div class=\"textbox textbox--sidebar left boxfigure\">\n<p>US-012: App Purpose<br \/>\nPriority: Highest (8)<br \/>\nSprint: 1<br \/>\nAssigned to: Randomira Philibert<\/p>\n<p>As a new user, I want to read about what features the app provides so that I can decide whether to use it.<\/p>\n<\/div>\n<\/div>\n<p class=\"captionstyle\"><strong>Figure 3.3\u00a0<\/strong>User Story Functional Requirement Examples<\/p>\n<p>Want more examples of user stories? Mountain Goat Software provides <a href=\"https:\/\/www.mountaingoatsoftware.com\/uploads\/documents\/example-user-stories.pdf\">200 example user stories [PDF]<\/a> (Cohn, <span class=\"citation\">2004<\/span>). They list only the \u201cAs a . . .\u201d part of the user story requirement.<\/p>\n<p>Anyone on the team\u2014or any project stakeholder\u2014might come up with user stories. Once the user stories are initially defined, they can be used to start a conversation with the client and others on the team. Clients can guide you on setting priorities for user stories. This conversation is also a good time to get more details about the user stories, which should be added to the card.<\/p>\n<div class=\"textbox textbox--sidebar\"><strong>Want examples of comically bad user stories? <\/strong>Check out the <a href=\"https:\/\/twitter.com\/shituserstory\">Shit User Story<\/a> Twitter feed (<span class=\"citation\">@ShitUserStory<\/span>)<\/div>\n<p>What makes a good user story? Besides the characteristics of good requirements listed earlier in this chapter, the <em>INVEST<\/em> acronym (Wake, <span class=\"citation\">2003<\/span>) can help you remember characteristics of good user stories:<\/p>\n<ul>\n<li>(I) <strong>Independent<\/strong>: Does not have unnecessary dependencies or overlap with other user stories.\n<ul>\n<li>Two user stories that overlap:\n<ul>\n<li>\u201cAs a new user, I want to register so that . . .\u201d<\/li>\n<li>\u201cAs a new user, I want to register using my Google account so that . . .\u201d<\/li>\n<\/ul>\n<\/li>\n<li>Set of user stories that don\u2019t overlap (but some user stories need to be completed before others\u2014that\u2019s ok):\n<ul>\n<li>\u201cAs a new user, I want to view the registration page so that . . .\u201d<\/li>\n<li>\u201cAs a new user, I want to register using Facebook so that . . .\u201d<\/li>\n<li>\u201cAs a new user, I want to register using Google so that . . .\u201d<\/li>\n<li>\u201cAs a new user, I want my registration details to be stored so that . . .\u201d<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<ul>\n<li>(N) <strong>Negotiable<\/strong>: Encourages instead of discourages discussion and gives developers flexibility.\n<ul>\n<li>Does not encourage discussion: \u201cAs a logged in user, I want to choose either black or white so that . . .\u201d<\/li>\n<li>Encourages discussion: \u201cAs a logged in user, I want to choose from multiple colors so that . . .\u201d<\/li>\n<\/ul>\n<\/li>\n<li>(V) <strong>Valuable<\/strong>: Fulfills a user need.\n<ul>\n<li>Does not fulfill a user need: \u201cAs an Enterprise user, I want to watch a little race car drive around the screen so that I can do something fun while requesting API end points.\u201d<\/li>\n<li>Fulfills a user need: \u201cAs an Enterprise user, I want to import my API end point requests so that my requests take less time and are less tedious.\u201d<\/li>\n<\/ul>\n<\/li>\n<li>(E) <strong>Estimable<\/strong>: Can be given a time estimate.\n<ul>\n<li>Difficult to give a time estimate: \u201cAs a new user, I want enough encouragement to register so that I\u2019ll register.\u201d<\/li>\n<li>Easier to estimate: \u201cAs a new user, I want to compare plan pricing so that I can decide which plan to choose.\u201d<\/li>\n<\/ul>\n<\/li>\n<li>(S) <strong>Small<\/strong>: Can fit into a single development period (e.g., a two-week Sprint)\n<ul>\n<li>Probably too large for a Sprint: \u201cAs a user, I want to play chess on my phone so that I have something to do while waiting at the pharmacy.\u201d<\/li>\n<li>Smaller: \u201cAs a user, I want to move my pawn so that I can take my turn in chess.\u201d<\/li>\n<\/ul>\n<\/li>\n<li>(T) <strong>Testable<\/strong>: Possible to determine it\u2019s done.\n<ul>\n<li>Difficult to determine whether it\u2019s done: \u201cAs a guest user, I want to be satisfied with my experience so that I will want to sign up.\u201d<\/li>\n<li>Less difficult: \u201cAs a guest user, I want to try out the AI text generator without registering first so that I can decide whether to subscribe.\u201d<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>There is some overlap between INVEST and the general characteristics of good requirements mentioned above (which is comforting), but you might find that INVEST is easier to remember.<\/p>\n<p>How do you know when a user story is done? This is negotiated with the client and added to the user story as acceptance criteria. Acceptance criteria say what must be true about the functionality specified by the user story for the user story to be considered done (i.e., establishing the Definition of Done for the user story). Figure 3.4 adds a DoD to one of the user stories from Figure 3.3. The DoD is composed of acceptance criteria following the given-when-then format.<\/p>\n<div class=\"boxcontainer\">\n<div class=\"textbox textbox--sidebar left boxfigure\">\n<p>US-023: Disabling Comments<br \/>\nPriority: Highest (8)<br \/>\nSprint: 2<br \/>\nAssigned to: Emrah Tuukka<\/p>\n<p>As an admin, I want to disable comments so that I can control spam and the spread of disinformation.<\/p>\n<p><strong>Definition of Done<\/strong><\/p>\n<ul>\n<li>Given the user is logged in as a user, when they navigate to \u201cSettings,\u201d then there is a \u201cDisable Comments\u201d button.<\/li>\n<li>Given the user is on the \u201cSettings\u201d page, when they activate \u201cDisable Comments,\u201d then a status message appears that indicates the action was successful. The message appears within 10 milliseconds.<\/li>\n<li>Given the user has activated \u201cDisable Comments,\u201d when they navigate to a \u201cPost\u201d page, then \u201cComments disabled\u201d appears in the \u201cComments\u201d section, and no comments are showing.<\/li>\n<\/ul>\n<\/div>\n<p class=\"captionstyle\"><strong>Figure 3.4\u00a0<\/strong>User Story with Definitions of Done Example<\/p>\n<p>Once each of the acceptance criteria are confirmed to be done, the user story can be considered \u201cDONE-done.\u201d<\/p>\n<p>Ideally, testing the acceptance criteria can be automated. Figure 3.5 provides example pseudocode for testing an acceptance criterion.<\/p>\n<div style=\"margin-top: 1em;\">\n<ol class=\"codestyle nolist\">\n<li><code><span class=\"red\">def<\/span> test_go_to_time():<\/code><\/li>\n<li><code>\u00a0\u00a0<span class=\"green\"># given<\/span><\/code><\/li>\n<li><code>\u00a0\u00a0assert os.isWindows(),<span class=\"blue\">\"Not Windows!\"<\/span><\/code><\/li>\n<li><code>\u00a0\u00a0player.<span class=\"red\">open<\/span>()<\/code><\/li>\n<li><code>\u00a0\u00a0player.play_video(<span class=\"blue\">'test.mkv'<\/span>)<\/code><\/li>\n<li><code><\/code><\/li>\n<li><code>\u00a0\u00a0<span class=\"green\"># when<\/span><\/code><\/li>\n<li><code>\u00a0\u00a0user.send_keyboard_shortcut(<span class=\"blue\">\"Ctrl-T\"<\/span>)<\/code><\/li>\n<li><code><\/code><\/li>\n<li><code>\u00a0\u00a0<span class=\"green\"># then<\/span><\/code><\/li>\n<li><code>\u00a0\u00a0assert player.screen.is_showing(GOTOTIME)<\/code><\/li>\n<\/ol>\n<p class=\"captionstyle\"><strong>Figure 3.5\u00a0<\/strong>Pseudocode for Testing an Example Acceptance Criterion<\/p>\n<\/div>\n<\/div>\n<h2>3.6.2 Use Cases<\/h2>\n<p>Use cases are a more formal method of specifying functional requirements. They are structured descriptions of what a system is required to do when a user interacts. Figure 3.2 showed a simple use case example, and additional examples can be found in the <a href=\"https:\/\/s3.amazonaws.com\/digitalgov\/_legacy-img\/2014\/01\/Marsh-Personas.pdf\">Digital.gov Usability Starter Kit PDF about use cases and personas<\/a> (US General Services Administration, <span class=\"citation\">2014<\/span>).<\/p>\n<p>As use cases are less common in Agile, the remainder of this section will provide only a summary of how use cases are structured.<\/p>\n<h3>Required Parts of a Use Case<\/h3>\n<p>Every use case has the following.<\/p>\n<ul>\n<li><strong>Name<\/strong>: A short title for the use case that often starts with a verb (e.g., \u201cSchedule weekly wellness check\u201d). The name briefly states the user objective the use case will describe.<\/li>\n<li><strong>Actor(s)<\/strong>: The user or users (human\/nonhuman\/computer) that are interacting with the software (e.g., \u201cMedical staff\u201d).<\/li>\n<li><strong>Flow of events<\/strong>: Sequence of actions describing the interaction between the actor and the software (a.k.a. \u201cbasic course of action\u201d or \u201csuccess scenario\u201d).<\/li>\n<\/ul>\n<p>Sometimes, the actor is implied through the flow of events (e.g., \u201cShopper selects the calendar icon\u201d). Other times, the actor is stated separately from the flow of events (e.g., \u201cActor: Shopper\u201d).<\/p>\n<h3>Additional Parts of a Use Case<\/h3>\n<p>The following are sometimes included in use cases.<\/p>\n<ul>\n<li><strong>Identifier<\/strong>: A unique way of referring to the use case (e.g., UC-002).<\/li>\n<li><strong>Preconditions<\/strong>: What must be true before the flow (e.g., \u201cThe shopper has added at least one product to their shopping cart\u201d).<\/li>\n<li><strong>Postconditions<\/strong>: What must be true after the flow (e.g., \u201cThe shopper received an order confirmation email\u201d).<\/li>\n<li><strong>Business relevance<\/strong>: Justification for why the use case exists.<\/li>\n<li><strong>Dependencies<\/strong>: Other use cases the use case relies on. The unique identifier is handy for this part.<\/li>\n<li><strong>Extensions<\/strong>: Contingencies, alternate routes, and branches to other use cases.<\/li>\n<li><strong>Priorities<\/strong>: The importance of the use case.<\/li>\n<li><strong>Nonfunctional requirements<\/strong>: How well the software must perform during the flow.<\/li>\n<\/ul>\n<h1>3.7 Requirements Specification<\/h1>\n<p>The process of writing down requirements is called requirements specification. Used as a noun, requirements specification refers to the document that contains the requirements. That document may also be a software requirements specification (SRS). The best way to learn about SRSs is to look at some.<\/p>\n<div class=\"textbox textbox--sidebar\">Another type of software document, which is sometimes confused with an SRS, is a software design document (SDD). If the SRS is what the software should be, the SDD is what the software is. There is often overlap between these two documents.<\/div>\n<p><strong>Freely available SRS examples<\/strong> (including some for open source software):<\/p>\n<ul>\n<li><a href=\"https:\/\/nvlpubs.nist.gov\/nistpubs\/ams\/NIST.AMS.300-2.pdf\">SRS for apps and a data repository for distributing manufacturing data [PDF]<\/a> (Hedberg et al., <span class=\"citation\">2017<\/span>).<\/li>\n<li><a href=\"https:\/\/www.nrcs.usda.gov\/publications\/ceap-watershed-2006-stewards-design.pdf\">SRS for data system that assesses conservation practices [PDF]<\/a> (CEAP, <span class=\"citation\">2006<\/span>).<\/li>\n<li><a href=\"http:\/\/selab.netlab.uky.edu\/~ashlee\/cs617\/project2\/PDFSam.pdf\">SRS for an app that splits and merges PDFs [PDF]<\/a> (Spyridonos, <span class=\"citation\">2010<\/span>).<\/li>\n<li><a href=\"http:\/\/openvibe.inria.fr\/openvibe\/wp-content\/uploads\/2018\/04\/CERT-Software-Requirement-Specification.pdf\">SRS for software that processes electroencephalography data [PDF]<\/a> (OpenVIBE, <span class=\"citation\">2018<\/span>).<\/li>\n<li><a href=\"https:\/\/vyasa.sourceforge.net\/vyasa_software_requirements_specification.pdf\">SRS for library software [PDF]<\/a> (Eaker, <span class=\"citation\">2006<\/span>).<\/li>\n<\/ul>\n<p>If any links are broken, try the <a href=\"https:\/\/web.archive.org\/\">Wayback Machine<\/a>.<\/p>\n<h1>3.8 Summary<\/h1>\n<p>There are two main types of software requirements: functional and nonfunctional.<\/p>\n<p>A functional requirement is \u201ca description of a behavior that a system will exhibit under specific conditions\u201d (Wiegers &amp; Beatty, 2013, p. 599). There are different formats for writing functional requirements such as the given-when-then format, user stories, and use cases. User stories are used in Agile software development. The given-when-then format is used for writing user story acceptance criteria. A set of acceptance criteria is used to determine whether a user story has been completed (Definition of Done).<\/p>\n<p>A nonfunctional requirement is \u201ca description of a property or characteristic that a system must exhibit or a constraint that it must respect\u201d (Wiegers &amp; Beatty, 2013, p. 600). Quality attributes are words for describing \u201ca service or performance characteristic of software\u201d (Wiegers &amp; Beatty, 2013, p. 601).<\/p>\n<p>There are standards for what makes a good requirement, such as being correct, unambiguous, complete, consistent, ranked for importance and\/or stability, verifiable, modifiable, and traceable. INVEST is an acronym for remembering standards for good user stories: independent, negotiable, valuable, estimable, small, and testable.<\/p>\n<p>An SRS can contain both nonfunctional and functional requirements.<\/p>\n<h1>References<\/h1>\n<p class=\"hanging-indent\">Agile Alliance. (n.d.). <em>What is \u201cgiven &#8211; when &#8211; then\u201d?<\/em> https:\/\/www.agilealliance.org\/glossary\/gwt\/<\/p>\n<p class=\"hanging-indent\">CEAP. Conservation Effects Assessment Project. (2006). <em>System requirements specification for STEWARDS. <\/em>US Department of Agriculture, Agricultural Research Service. <a href=\"https:\/\/www.nrcs.usda.gov\/publications\/ceap-watershed-2006-stewards-design.pdf\">https:\/\/www.nrcs.usda.gov\/publications\/ceap-watershed-2006-stewards-design.pdf<\/a><\/p>\n<p class=\"hanging-indent\">Cohn, M. (2004). <em>Example user stories<\/em>. Mountain Goat Software. <a href=\"https:\/\/www.mountaingoatsoftware.com\/uploads\/documents\/example-user-stories.pdf\">https:\/\/www.mountaingoatsoftware.com\/uploads\/documents\/example-user-stories.pdf<\/a><\/p>\n<p class=\"hanging-indent\">Eaker, F. (2006, November). <em>Software requirements specification<\/em>. Vyasa. <a href=\"https:\/\/vyasa.sourceforge.net\/vyasa_software_requirements_specification.pdf\">https:\/\/vyasa.sourceforge.net\/vyasa_software_requirements_specification.pdf<\/a><\/p>\n<p class=\"hanging-indent\">Hanington, B. M., &amp; Martin, B. (2019). <em>Universal Methods of Design: 125 ways to research complex problems, develop innovative ideas, and design effective solutions<\/em>. Rockport Publishers.<\/p>\n<p class=\"hanging-indent\">Hedberg, T., Helu, M., &amp; Newrock, M. (2017, December). <em>Software requirements specification to distribute manufacturing data<\/em>. NIST Advanced Manufacturing Series 300-2. National Institute of Standards and Technology. <a href=\"https:\/\/nvlpubs.nist.gov\/nistpubs\/ams\/NIST.AMS.300-2.pdf\">https:\/\/nvlpubs.nist.gov\/nistpubs\/ams\/NIST.AMS.300-2.pdf<\/a><\/p>\n<p class=\"hanging-indent\">OpenVIBE. (2018, April). <em>Inria Innovation Lab Certivibe v 1.0 software requirement specification<\/em>. <a href=\"http:\/\/openvibe.inria.fr\/openvibe\/wp-content\/uploads\/2018\/04\/CERT-Software-Requirement-Specification.pdf\">http:\/\/openvibe.inria.fr\/openvibe\/wp-content\/uploads\/2018\/04\/CERT-Software-Requirement-Specification.pdf<\/a><\/p>\n<p class=\"hanging-indent\">@ShitUserStory. (n.d.). <em>Shit User Story<\/em>. Twitter. <a href=\"https:\/\/twitter.com\/shituserstory\">https:\/\/twitter.com\/shituserstory<\/a><\/p>\n<p class=\"hanging-indent\">Spyridonos, P. (2010, February 6). <em>Software requirements specification for PDF split and merge requirements for version 2.1.0<\/em>. University of Kentucky Software Verification and Validation Lab. <a href=\"https:\/\/selab.netlab.uky.edu\/~ashlee\/cs617\/project2\/PDFSam.pdf\">https:\/\/selab.netlab.uky.edu\/~ashlee\/cs617\/project2\/PDFSam.pdf<\/a><\/p>\n<p class=\"hanging-indent\">\u00a0Texas Department of Information Resources. (2008, January 14). <em>Software requirements specification instructions<\/em>. <a href=\"https:\/\/dir.texas.gov\/sites\/default\/files\/Requirements%20Traceability%20Matrix%20Instructions.pdf\">https:\/\/dir.texas.gov\/sites\/default\/files\/Requirements%20Traceability%20Matrix%20Instructions.pdf<\/a><\/p>\n<p class=\"hanging-indent\">US General Services Administration. (2014, January). <em>USDA personas and use cases<\/em>. <a href=\"https:\/\/s3.amazonaws.com\/digitalgov\/_legacy-img\/2014\/01\/Marsh-Personas.pdf\">https:\/\/s3.amazonaws.com\/digitalgov\/_legacy-img\/2014\/01\/Marsh-Personas.pdf<\/a><\/p>\n<p class=\"hanging-indent\">Wake, B. (2003, August 17). <em>Invest in good stories, and Smart Tasks<\/em>. XP123 Exploring Extreme Programming. <a href=\"https:\/\/xp123.com\/articles\/invest-in-good-stories-and-smart-tasks\/\">https:\/\/xp123.com\/articles\/invest-in-good-stories-and-smart-tasks\/<\/a><\/p>\n<p class=\"hanging-indent\">Wiegers, K., &amp; Beatty, J. (2013). <em>Software requirements<\/em> (3rd ed.). Developer Best Practices Series. Microsoft Press.<\/p>\n<p class=\"hanging-indent\">Wikimedia Foundation. (2023, March 23). <em>List of system quality attributes<\/em>. <a href=\"https:\/\/en.wikipedia.org\/wiki\/List_of_system_quality_attributes\">https:\/\/en.wikipedia.org\/wiki\/List_of_system_quality_attributes<\/a><\/p>\n<div class=\"glossary\"><span class=\"screen-reader-text\" id=\"definition\">definition<\/span><template id=\"term_31_883\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_31_883\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_31_838\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_31_838\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_31_839\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_31_839\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_31_663\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_31_663\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_31_840\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_31_840\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_31_841\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_31_841\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_31_842\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_31_842\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_31_843\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_31_843\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_31_660\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_31_660\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_31_844\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_31_844\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_31_652\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_31_652\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_31_846\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_31_846\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_31_847\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_31_847\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_31_848\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_31_848\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_31_849\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_31_849\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_31_664\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_31_664\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_31_850\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_31_850\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_31_851\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_31_851\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_31_852\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_31_852\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_31_853\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_31_853\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_31_650\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_31_650\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_31_657\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_31_657\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_31_854\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_31_854\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_31_662\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_31_662\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_31_855\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_31_855\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_31_856\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_31_856\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_31_661\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_31_661\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_31_857\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_31_857\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_31_858\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_31_858\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_31_653\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_31_653\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_31_649\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_31_649\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_31_659\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_31_659\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_31_656\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_31_656\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_31_651\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_31_651\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><\/div>","protected":false},"author":1,"menu_order":3,"template":"","meta":{"pb_show_title":"","pb_short_title":"Requirements","pb_subtitle":"","pb_authors":[],"pb_section_license":""},"chapter-type":[48],"contributor":[],"license":[],"class_list":["post-31","chapter","type-chapter","status-publish","hentry","chapter-type-standard"],"part":19,"_links":{"self":[{"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/pressbooks\/v2\/chapters\/31","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/pressbooks\/v2\/chapters"}],"about":[{"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/wp\/v2\/types\/chapter"}],"author":[{"embeddable":true,"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/wp\/v2\/users\/1"}],"version-history":[{"count":1,"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/pressbooks\/v2\/chapters\/31\/revisions"}],"predecessor-version":[{"id":32,"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/pressbooks\/v2\/chapters\/31\/revisions\/32"}],"part":[{"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/pressbooks\/v2\/parts\/19"}],"metadata":[{"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/pressbooks\/v2\/chapters\/31\/metadata\/"}],"wp:attachment":[{"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/wp\/v2\/media?parent=31"}],"wp:term":[{"taxonomy":"chapter-type","embeddable":true,"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/pressbooks\/v2\/chapter-type?post=31"},{"taxonomy":"contributor","embeddable":true,"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/wp\/v2\/contributor?post=31"},{"taxonomy":"license","embeddable":true,"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/wp\/v2\/license?post=31"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}