{"id":2221,"date":"2020-01-28T02:55:51","date_gmt":"2020-01-27T23:55:51","guid":{"rendered":"http:\/\/kusuaks7\/?p=1826"},"modified":"2024-01-23T15:31:44","modified_gmt":"2024-01-23T15:31:44","slug":"part-2-developing-software-requirements-a-case-study","status":"publish","type":"post","link":"https:\/\/www.experfy.com\/blog\/bigdata-cloud\/part-2-developing-software-requirements-a-case-study\/","title":{"rendered":"Part 2: Developing Software Requirements, A Case Study"},"content":{"rendered":"\t\t<div data-elementor-type=\"wp-post\" data-elementor-id=\"2221\" class=\"elementor elementor-2221\" data-elementor-post-type=\"post\">\n\t\t\t\t\t\t<section class=\"has_eae_slider elementor-section elementor-top-section elementor-element elementor-element-1271def4 elementor-section-boxed elementor-section-height-default elementor-section-height-default\" data-id=\"1271def4\" data-element_type=\"section\" data-e-type=\"section\">\n\t\t\t\t\t\t<div class=\"elementor-container elementor-column-gap-default\">\n\t\t\t\t\t<div class=\"has_eae_slider elementor-column elementor-col-100 elementor-top-column elementor-element elementor-element-6da99e68\" data-id=\"6da99e68\" data-element_type=\"column\" data-e-type=\"column\">\n\t\t\t<div class=\"elementor-widget-wrap elementor-element-populated\">\n\t\t\t\t\t\t<div class=\"elementor-element elementor-element-302c052c elementor-widget elementor-widget-text-editor\" data-id=\"302c052c\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t<em>This is Part 2 of a 4 part series.<\/em>Part 1: Why Software Requirements In The Real World Are Hard\u00a0<em>discusses the challenges of developing requirements and what good ones might look like. This post looks at the requirements development process and its outputs on a real-world project.<\/em>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-a8cb911 elementor-widget elementor-widget-heading\" data-id=\"a8cb911\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"heading.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t<h2 class=\"elementor-heading-title elementor-size-default\"><h2>TL;DR<\/h2><\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-e586c21 elementor-widget elementor-widget-text-editor\" data-id=\"e586c21\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\tThe familiar dichotomy between agile approaches that prioritise shipping software to elicit real requirements and waterfall approaches that prioritise upfront requirements engineering is overly simplistic. In between these poles, there\u2019s an intermediate approach for developing requirements that is easy enough to implement and better at delivering value to users and stakeholders. Features and benefits of this approach include:\n<ul>\n \t<li>Defining a process for requirements development that is iterative, produces standard and agreed upon outputs, and integrates with a broader agile delivery approach<\/li>\n \t<li>Leveraging cheap experiments (e.g. rapid prototyping) to get going quickly in an evidence-based way without shipping fully working software<\/li>\n \t<li>Using a hierarchy (usually associated with requirements engineering) to provide useful context for users and stakeholders at appropriate levels of abstraction<\/li>\n \t<li>Selectively populating the hierarchy (not necessarily top-down) so that the development team and others have the context they need to align and make better decisions.<\/li>\n<\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-c0a44d0 elementor-widget elementor-widget-heading\" data-id=\"c0a44d0\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"heading.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t<h2 class=\"elementor-heading-title elementor-size-default\"><h2>Vision Coach<\/h2><\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-c2ce4bc elementor-widget elementor-widget-text-editor\" data-id=\"c2ce4bc\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\tVision Coach is the real-world project I\u2019ll use as a way into this topic. It\u2019s a platform my team built in partnership with Bayer Healthcare for patients living with, and doctors treating, an eye disease called\u00a0diabetic macular edema\u00a0(DME\/DMO). DME affects c.21 million people with diabetes globally and is the leading cause of blindness in adults of working age.\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-9c091d3 elementor-widget elementor-widget-text-editor\" data-id=\"9c091d3\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\tBayer Healthcare provides a therapy that is one of a class of therapies that eye doctors use to improve the vision of people with retinal diseases like DME. Despite being a sight-threatening condition, patient adherence to therapy is poor, meaning vision outcomes are often suboptimal. Addressing this problem formed the focus of the project.\n<blockquote>For ease, I&#8217;ve stuck with traditional terms throughout &#8211; e.g. \u201crequirements, elicitation, specification\u201d. Though not perfect (isn&#8217;t calling hypotheses &#8220;requirements&#8221; weird?), they have the advantage of being familiar.<\/blockquote>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-e066fb7 elementor-widget elementor-widget-heading\" data-id=\"e066fb7\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"heading.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t<h2 class=\"elementor-heading-title elementor-size-default\"><h2>Requirements approach<\/h2><\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-563982d elementor-widget elementor-widget-text-editor\" data-id=\"563982d\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\tDebates about how to do requirements often centre on two antithetical approaches that I\u2019ll call\u00a0<em>Analysis paralysis<\/em>\u00a0and\u00a0<em>Iteration worship<\/em>.\u00a0<em>Analysis paralysis<\/em>\u00a0says you must elicit and specify requirements upfront before any coding can start, they must have a perfect set of attributes (consistency, lack of ambiguity, completeness etc), and if this takes weeks or even months of effort, so be it.\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-a0743a0 elementor-widget elementor-widget-text-editor\" data-id=\"a0743a0\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t<em>Iteration worship<\/em>\u00a0says the opposite &#8211; the best way to elicit requirements is to build something and test it out with users. Users don\u2019t know what they want, or at least can\u2019t always articulate it, and it\u2019s not until they\u2019re presented with working software that their true requirements emerge. Upfront specification is therefore a waste of time.\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-08d209f elementor-widget elementor-widget-text-editor\" data-id=\"08d209f\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\tVery broadly, this describes waterfall and agile approaches to requirements development. The two are opposites, and it\u2019s usually assumed you\u2019re on one side or the other. So which side are you on?\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-291b7f0 elementor-widget elementor-widget-text-editor\" data-id=\"291b7f0\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\tWell, obviously you\u2019re not on the side of\u00a0<em>Analysis paralysis<\/em>. Spending lots of time eliciting requirements from stakeholders, making them consistent, complete, testable (and all the rest) before you start coding is futile in the face of uncertainty and change, and all it does successfully is raise the cost of failure and learning.\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-89761f5 elementor-widget elementor-widget-text-editor\" data-id=\"89761f5\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\tWhich is no good if you need to fail and learn a lot, like most teams. Oh, and the fact it doesn\u2019t work is well evidenced &#8211; the\u00a0<a href=\"https:\/\/www.projectsmart.co.uk\/white-papers\/chaos-report.pdf\" rel=\"noopener\">Standish Group\u2019s Chaos survey<\/a>\u00a0is one source frequently wheeled out as proof.\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-58c383f elementor-widget elementor-widget-text-editor\" data-id=\"58c383f\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\tSo that means you\u2019re on the\u00a0<em>Iteration worship<\/em>\u00a0side, right? Well no, at least not as it\u2019s been characterised (or caricatured?) here. This approach has problems too. First, it\u2019s simply not true that you can\u2019t say anything valuable about requirements without first shipping software to users &#8211; rapid prototyping using wireframing tools is one technique capable of eliciting useful evidence for requirements before coding starts.\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-3ed595d elementor-widget elementor-widget-text-editor\" data-id=\"3ed595d\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\tSecond, iterations aren\u2019t actually that cheap &#8211; sure, they\u2019re cheaper than delivering software waterfall-style, but they\u2019re still expensive vs. techniques like rapid prototyping.\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-cbf74f5 elementor-widget elementor-widget-text-editor\" data-id=\"cbf74f5\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\tThird, if you genuinely spend no time defining your requirements, what you build is likely to be further away from your target, necessitating more iterations to get there.\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-275b0ba elementor-widget elementor-widget-text-editor\" data-id=\"275b0ba\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\tOur approach fell somewhere in between the two &#8211; some specification up front combined with shipping working software early to elicit further requirements from users in higher fidelity experiments.\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-e00c3a1 elementor-widget elementor-widget-heading\" data-id=\"e00c3a1\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"heading.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t<h2 class=\"elementor-heading-title elementor-size-default\"><h2>Process and hierarchy<\/h2><\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-2f157dd elementor-widget elementor-widget-text-editor\" data-id=\"2f157dd\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\tIn Part 1, I identified some key properties of a requirements development process and its outputs &#8211; e.g. it needs to be collaborative, iterative, and its outputs need to be tailored to different audiences. Going beyond this, it\u2019s helpful to define a process and identify techniques for optimising outputs.\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-44eebb1 elementor-widget elementor-widget-text-editor\" data-id=\"44eebb1\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\tIt consisted of four activities:\n<ul>\n \t<li><strong>Elicitation<\/strong>\u00a0&#8211; Drawing requirements out of users and stakeholders using a variety of techniques<\/li>\n \t<li><strong>Analysis<\/strong>\u00a0&#8211; Understanding the underlying problems to be solved, refining user and stakeholder requirements, and combining this with system requirements<\/li>\n \t<li><strong>Specification<\/strong>\u00a0&#8211; Formulating requirements using a hierarchy and agreed templates, and documenting them<\/li>\n \t<li><strong>Validation<\/strong>\u00a0&#8211; Verifying requirements are as accurate as they can be given the evidence, and can be verified as being done once implemented.<\/li>\n<\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-698a5a0 elementor-widget elementor-widget-text-editor\" data-id=\"698a5a0\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t<p style=\"text-align: center;\">\u00a0Requirements development process (adapted from Wiegers &amp; Beatty, <em>Software Requirements<\/em>, 3rd Edition).<\/p>\nThe process was iterative and involved moving back and forth between different activities, often in the same session, meaning faster feedback loops and better outputs. It also involved a review and approval decision point for client stakeholders, which was required before any coding could start. Beyond this, it was integrated into the broader Scrum process we used to deliver the project, which consisted of 2-week sprints, daily standups, client showcases and retrospectives at the end of the sprint, and planning at the start of the next.\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-091fa04 elementor-widget elementor-widget-text-editor\" data-id=\"091fa04\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\tAdditionally, we defined a hierarchy that consisted of the levels shown in Figure 2.\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-9ef701f elementor-widget elementor-widget-text-editor\" data-id=\"9ef701f\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\tWhy define a hierarchy? Different people need different information captured at different levels of abstraction. On Vision Coach, client stakeholders spent time reviewing the vision, scope, user stories and high-level features, but weren\u2019t interested in technical designs or tasks.\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-20dfe4a elementor-widget elementor-widget-text-editor\" data-id=\"20dfe4a\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\tA delivery team also needs context for decisions, which a sensible hierarchy can provide.\n<p style=\"text-align: center;\">\u00a0The requirements hierarchy.<\/p>\nDefining the hierarchy was the easy part. Populating it was more time consuming, but given we weren\u2019t in the analysis paralysis game and had a small team, we populated only as much as we needed to upfront to get going. Initially this involved more work at the vision &amp; scope levels to get the project greenlit, and then at the lower levels.\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-dadbae8 elementor-widget elementor-widget-text-editor\" data-id=\"dadbae8\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\tImportantly, we didn\u2019t always populate the hierarchy top-down, a good example being a scope change, where we might document only a user story and tasks if it fitted with existing features and non-functional requirements and wasn\u2019t sufficiently contentious or complex to call for technical designs.\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-9d899cc elementor-widget elementor-widget-text-editor\" data-id=\"9d899cc\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\tWhich is to say, we used the hierarchy more as a guide than an enforceable schema &#8211; it helped us structure requirements when we needed to produce them at the appropriate level(s) of abstraction.\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-f2019ee elementor-widget elementor-widget-heading\" data-id=\"f2019ee\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"heading.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t<h2 class=\"elementor-heading-title elementor-size-default\"><h2>Elicitation<\/h2><\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-9bce44e elementor-widget elementor-widget-text-editor\" data-id=\"9bce44e\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\tHealthcare is complicated. There are lots of stakeholders, usually related in complex ways. These include patients, doctors, clinics, hospitals, payers, regulators\u2026 the list is extensive. Direct engagement with all of them is impractical, so you create representative proxies, which was our approach here.\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-1af5bb2 elementor-widget elementor-widget-text-editor\" data-id=\"1af5bb2\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t\nRequirements and constraints (conditions placed on requirements) came from a large number of stakeholder groups. Here are the main ones (there were others!):\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-5e16731 elementor-widget elementor-widget-text-editor\" data-id=\"5e16731\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t<strong>Users<\/strong>\n<ul>\n \t<li><strong>Patients<\/strong>. Patients were generally of working age (55 or older), had been living with diabetes for a number of years, and had started to develop complications like DME as their disease progressed. Direct interaction with this group was governed by strict regulations (more on this later), which made user testing more difficult than usual.<\/li>\n \t<li><strong>Doctors<\/strong>. The doctors were ophthalmologists (specialist eye doctors) who worked with teams of other doctors, technicians and administrators in stand-alone clinics or clinics within hospitals in a mix of public and private settings.<\/li>\n \t<li><strong>Clinics and hospitals<\/strong>. The organisation in which doctors treated patients. The larger organisations had well-developed corporate functions like IT, Clinical Governance and Information Governance, all of which had requirements.<\/li>\n<\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-9f923bb elementor-widget elementor-widget-text-editor\" data-id=\"9f923bb\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t<strong>Client functions<\/strong>\n<ul>\n \t<li><strong>Marketing<\/strong>. The global ophthalmology marketing team commissioned and managed the project. They had requirements related to business priorities and the use of evidence (qualitative and quantitative studies) to guide our work.<\/li>\n \t<li><strong>IT<\/strong>. Business rules documented in policies and procedures mandated ways of working and, on occasion, use of specific technologies. Requirements covered things like design guidelines, cookies, user consent, web analytics and certificate management.<\/li>\n \t<li><strong>Security<\/strong>. The system stores identifiable patient data, which is subject to stringent controls. Security requirements were distilled into a vendor security assessment. Separately, we received requirements for external pen testing, distributed denial of service (DDoS) protection using named suppliers and certification against the\u00a0<a href=\"https:\/\/en.wikipedia.org\/wiki\/ISO\/IEC_27001\" rel=\"noopener\">ISO27001<\/a>\u00a0standard for information security.<\/li>\n \t<li><strong>Compliance<\/strong>. Vision Coach had to go through legal, medical and regulatory (LMR) compliance review before it could be used by patients and doctors. This involved global and local review against requirements in these different domains. Reviews would usually elicit new requirements.<\/li>\n<\/ul>\n<strong>Client suppliers<\/strong>\n<ul>\n \t<li><strong>Translation agency<\/strong>. The agency translating the global english copy into 12 translated and localised versions had requirements and constraints around the technology and process used.<\/li>\n<\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-a3c694c elementor-widget elementor-widget-text-editor\" data-id=\"a3c694c\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t<strong>Us<\/strong>\n<ul>\n \t<li><strong>Delivery team<\/strong>. We were a small team with a number of roles: Developers, Testers, DevOps, a Technical Architect, Product Owner (PO), Project Manager, User Experience (UX), UI Design and clinical domain expert. The PO and UX leads elicited requirements.<\/li>\n<\/ul>\nFor the client, we created a core team at the global level to represent key client functions across the business. We elicited requirements from this group, and if we needed to speak with other stakeholders (e.g. specialists in fields like medical device regulation or data privacy) this was facilitated by this team.\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-640cd2b elementor-widget elementor-widget-text-editor\" data-id=\"640cd2b\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\tFor patients and doctors, elicitation was more complicated, as pharma companies (and their suppliers) are bound by strict regulations and internal processes for communicating with them, meaning user testing isn\u2019t easy, quick or cheap.\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-8bf6029 elementor-widget elementor-widget-text-editor\" data-id=\"8bf6029\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\tLuckily, in the first instance, we had access to clinical expertise internally, and were able to rely on extensive market research and user testing with patients of a previous similar(ish) prototype. On an ongoing basis, we elicited requirements using a mixture of observation, interviews, workshops, testing with prototypes (built to differing levels of fidelity) and ad-hoc follow up.\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-b9019ea elementor-widget elementor-widget-heading\" data-id=\"b9019ea\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"heading.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t<h2 class=\"elementor-heading-title elementor-size-default\"><h2>Analysis, specification &amp; validation<\/h2><\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-b0c23ff elementor-widget elementor-widget-text-editor\" data-id=\"b0c23ff\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\tElicitation outputs were documented by the PO and UX lead, usually as unstructured notes in the first instance, which were played back to client stakeholders for review and approval. These were then collated by the PO and turned into user stories (Level 2 in our hierarchy) and documented in a Jira ticket using an agreed template that included:\n<ul>\n \t<li>An agile user story in the form \u201cAs a [type of user], I want [some goal], so that [some reason]\u201d<\/li>\n \t<li>Background\/rationale explaining why the requirement was important<\/li>\n \t<li>Acceptance criteria using\u00a0<a href=\"https:\/\/cucumber.io\/docs\/gherkin\/reference\/#steps\" rel=\"noopener\">Gherkin\u2019s steps syntax<\/a>\u00a0covering primary and alternate goals<\/li>\n \t<li>Links to wireframes, UI designs and other relevant artifacts.<\/li>\n<\/ul>\nDiscussion with the internal delivery team started in backlog refinement sessions, the goal of which was to refine stories, nail down acceptance criteria, and augment them with features, non-functional requirements, technical designs and tasks (Levels 3-5).\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-2623fdb elementor-widget elementor-widget-text-editor\" data-id=\"2623fdb\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\tDiscussion was finished off in planning, where we compiled a sprint backlog of requirements that met our Definition of Ready. Disagreements about technical designs, often due to complexity, were the cue for further design work, which we did in design sessions during sprints.\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-94d48f8 elementor-widget elementor-widget-text-editor\" data-id=\"94d48f8\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\tIn all these sessions the PO, with support from appropriate domain experts, represented users and client stakeholders to the developers, helping to answer their questions and guide their decisions.\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-e528dca elementor-widget elementor-widget-text-editor\" data-id=\"e528dca\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\tThis is how we specified artifacts at Levels 3-5 in our hierarchy:\n<ul>\n \t<li><strong>Features and non-functional requirements<\/strong>\u00a0(NFRs; Level 3) were captured at a high-level in Jira epics, accompanied by a brief description and links to wireframes, designs etc, and were used to group related user stories. We documented NFRs as separate docs using the same approach as technical designs (see next bullet), and used acceptance criteria in our user stories to help surface them early on.<\/li>\n \t<li><strong>Technical designs<\/strong>\u00a0(Level 4) consisted of a mixture of prose and diagrams and were documented in reStructuredText and PlantUML, stored in a git repo and rendered to static html using Sphinx and the Read the Docs theme, with links to the hosted docs created in our Jira project. These days we\u2019ve changed our docs stack pretty significantly, but the\u00a0<a href=\"https:\/\/www.writethedocs.org\/guide\/docs-as-code\/\" rel=\"noopener\">docs as code approach<\/a>\u00a0is still something we like a lot.<\/li>\n \t<li><strong>Tasks\u00a0<\/strong>(Level 5) were documented as subtasks of the user story parent ticket in Jira and generally took the form of lists of work in, and out of, scope. This added granularity to a story\u2019s acceptance criteria and allowed us to verify that a story had been done (part of the validation step in our process).<\/li>\n<\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-13bf414 elementor-widget elementor-widget-heading\" data-id=\"13bf414\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"heading.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t<h2 class=\"elementor-heading-title elementor-size-default\"><h2>Example requirements<\/h2><\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-7f22724 elementor-widget elementor-widget-text-editor\" data-id=\"7f22724\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\tLet\u2019s look at a thin vertical slice of our hierarchy from onboarding for the patient mobile app to see how the outputs turned out. It includes a mix of content that applies to the platform globally as well as to patient app onboarding only.\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-86cac7d elementor-widget elementor-widget-text-editor\" data-id=\"86cac7d\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t<strong>Vision and scope (Level 1)<\/strong>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-ee8b582 elementor-widget elementor-widget-text-editor\" data-id=\"ee8b582\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t\nWe used this\u00a0neat template (originally from Geoffrey Moore&#8217;s\u00a0<em>Crossing the Chasm)\u00a0<\/em>to capture the vision and scope succinctly:\n<ul>\n \t<li><strong>For<\/strong>\u00a0patients with diabetic eye disease (<em>target user<\/em>)<\/li>\n \t<li><strong>Who<\/strong>\u00a0typically adhere poorly to therapy (<em>statement of need or opportunity<\/em>)<\/li>\n \t<li><strong>The<\/strong>\u00a0Vision Coach service (<em>product name<\/em>)<\/li>\n \t<li><strong>Is<\/strong>\u00a0a mobile app (<em>product category<\/em>)<\/li>\n \t<li><strong>That<\/strong>\u00a0provides access to key health data, help understanding it and tools to take action to improve adherence, vision outcomes and general health (<em>key benefits<\/em>)<\/li>\n \t<li><strong>Unlike\u00a0<\/strong>other apps for people with diabetes (<em>primary competitive alternative<\/em>)<\/li>\n \t<li><strong>Our product<\/strong>\u00a0addresses diabetic eye disease in addition to the underlying diabetes (<em>statement of primary differentiation<\/em>)<\/li>\n<\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-fe49624 elementor-widget elementor-widget-text-editor\" data-id=\"fe49624\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t<strong>User stories (Level 2)<\/strong>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-6091db7 elementor-widget elementor-widget-text-editor\" data-id=\"6091db7\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t\nThe onboarding epic collected together all the user stories for onboarding, which consisted of two separate flows &#8211; sign up and login. Figure 3 shows a screenshot of a story in both flows &#8211; SMS-based one-time password (OTP) verification. It uses the template described above, and has acceptance criteria covering both primary and alternate goals.\n<p style=\"text-align: center;\">Example user story for account verification during onboarding<\/p>\n<strong>Features and non-functional requirements (Level 3)<\/strong>\n\n<em>Features<\/em>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-24e274d elementor-widget elementor-widget-text-editor\" data-id=\"24e274d\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t<em>Features<\/em>\n\nThe onboarding feature was captured in a Jira epic as lists for the separate sign up and login flows.\n\nSign up:\n<ul>\n \t<li>Confirm region and language<\/li>\n \t<li>Consent to terms and conditions<\/li>\n \t<li>Enter phone number<\/li>\n \t<li>Verify SMS one-time password (OTP)<\/li>\n \t<li>Enter user name<\/li>\n \t<li>Confirm treatment plan<\/li>\n<\/ul>\nLogin:\n<ul>\n \t<li>Enter phone number<\/li>\n \t<li>Verify SMS OTP<\/li>\n<\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-2bb674d elementor-widget elementor-widget-text-editor\" data-id=\"2bb674d\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\tIt was supplemented by the quasi activity diagram shown in Figure 4, and linked to related user stories.\n<p style=\"text-align: center;\">Patient mobile app onboarding flow.<\/p>\n<em>Non-functional requirements (NFRs)<\/em>\n<ul>\n \t<li><strong>Security<\/strong>\u00a0was important as the system stores patient data, a sensitive class of personal data as defined by GDPR. More broadly, we were required to comply with and certify against ISO27001, an industry standard for information security, part of which covers controls for user authentication. This required a lot of effort, and impacted our technical designs and implementations, as well as our processes, people and locations more broadly. Ongoing annual audits by a mutually agreed auditor also meant it wasn\u2019t a one off.<\/li>\n \t<li><strong>Internationalisation (i18n) and localisation (l10n)<\/strong>\u00a0was important since the app was initially designed for use in 10 countries with 12 local copy sets. There was also a project requirement for all translation work to be carried out by an approved translation agency. This ended up impact process more than product.<\/li>\n \t<li><strong>Legal<\/strong>\u00a0was extremely important given the compliance requirements around patient data originating from laws, regulations, standards and contracts. Data sovereignty (the country in which data is stored) is important when dealing with patient data (both for real and perceived reasons). For Vision Coach, patient data needed to live in a number of different global regions. Consent for optional analytics data sharing captured in onboarding also needed to be stored and renewed at least annually (in line with EU law).<\/li>\n \t<li><strong>Accessibility<\/strong>\u00a0was relevant given some users were visually impaired (ranging from mild to severe). A constraint on this was the rich accessibility tooling provided natively by iOS and Android, and some evidence (admittedly in a much broader population) that these tools were frequently used by users with visual impairment (e.g. screen readers, as in the acceptance criteria in Figure 3).<\/li>\n \t<li><strong>Performance &amp; scalability<\/strong>\u00a0were important as the system needed to respond within a minimum amount of time for it to be usable, so the way we deployed the infrastructure needed to be able to support a best case estimate of user numbers, especially where it was heavily loaded.<\/li>\n<\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-971e3b3 elementor-widget elementor-widget-text-editor\" data-id=\"971e3b3\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t<strong>Technical designs (Level 4)<\/strong>\n<ul>\n \t<li><strong>Authentication<\/strong>. Figure 5 shows a UML sequence diagram for the broad authentication flow, including phone number verification using an SMS-based OTP. We didn&#8217;t produce many sequence diagrams for the app, but the authentication flow was one area where we did, in this instance because there was disagreement on the technical design. Disagreement and complexity were normally our triggers for doing more work in technical design sessions, as mentioned, and sequence and other diagrams were occasionally outputs of these, when deemed useful for analysing requirements and improving team alignment.<\/li>\n<\/ul>\nUML sequence diagram showing the end-to-end authentication flow\n<ul>\n \t<li><strong>I18n and l10n<\/strong>. Since translation work was done by an external agency, translated content needed to be in a form that was easy to move back and forth during the process. We decided to use a common framework for the various apps that made up Vision Coach. All of the content was stored in yaml files, which were factored out of any individual application and loaded at runtime. For the patient app, on start up the app loads content from a translation API.<\/li>\n \t<li><strong>User consent<\/strong>. Users are asked for consent to track application usage as part of the terms of service consent. We needed to record the consent event and send it to a third-party API specified by IT stakeholders at the client. Consent information then needed to be made available to multiple applications and devices, which was was done through data stored in the authenticated API in the case of the patient app.<\/li>\n \t<li><strong>SMS services<\/strong>. We chose to use Amazon Web Service\u2019s (AWS) Simple Notification Service (SNS) for sending transactional SMS messages. This was a decision of convenience, given the application was hosted on AWS.<\/li>\n \t<li><strong>Regional deployment<\/strong>. Due to the requirement of keeping patient data within certain regions, we needed to deploy the platform to multiple AWS regions. This gave the added advantage of improving latency for global customers. Only one version of the patient app was needed and we used a single global endpoint well known to allow it to discover regional resources such as APIs and authentication services. Figure 6 shows the regional deployment. It includes one primary region (EU) that hosts static services, and separate regions that host API services (backed by AWS Relational Database Service (RDS) and a\u00a0<a href=\"https:\/\/medium.com\/healthforge\/kaji-a-general-purpose-fhir-clinical-data-repository-d56e4b99ef2d\" class=\"broken_link\" rel=\"noopener\">clinical data repository<\/a>\u00a0based on the HL7\u00a0<a href=\"https:\/\/www.hl7.org\/fhir\/\" rel=\"noopener\">FHIR<\/a>\u00a0standard) and authentication services. The mobile app gets its configuration data about where the appropriate region is located (based on the phone\u2019s locale ID) from the config service in the primary EU environment, and thereafter its data from the appropriate regional environment<\/li>\n<\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-f5b4b49 elementor-widget elementor-widget-text-editor\" data-id=\"f5b4b49\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t<p style=\"text-align: center;\">\u00a0Vision Coach regional deployment<\/p>\n\n<ul>\n \t<li><strong>High availability deployment<\/strong>. Application usage levels were difficult to predict in advance, which was part of the reason we deployed on AWS\u2019s Elastic Container Service (ECS), as it enabled us to scale the application easily if required, as well as keep costs under control despite the multi-region set up.<\/li>\n<\/ul>\n<strong>Tasks (Level 5)<\/strong>\n\nImplementation work was documented in sub-tasks attached to the parent ticket in Jira. Generally we took an incremental approach to implementation, starting with a minimum viable product (MVP), and layering up functionality from there. Staying with the phone number verification story, front- and back-end (FE &amp; BE) tasks included:\n<ul>\n \t<li>Basic OTP input box (FE)<\/li>\n \t<li>API call to validate OTP verification completion (FE)<\/li>\n \t<li>UI control to navigate to previous screen (FE)<\/li>\n \t<li>Additional integration work once real API was available (FE)<\/li>\n \t<li>Implement mock API endpoint for front-end developers to work against early on (BE)<\/li>\n \t<li>Implement real API endpoint to validate OTP against value stored in the database (BE)<\/li>\n<\/ul>\nIncrements beyond MVP included the following tasks (FE &amp; BE):\n<ul>\n \t<li>Automatic submission of OTP on entry of last digit in verification code<\/li>\n \t<li>Automatic routing to next screen in onboarding on OTP validation<\/li>\n \t<li>Resending OTP where delivery fails<\/li>\n<\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-d413036 elementor-widget elementor-widget-heading\" data-id=\"d413036\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"heading.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t<h2 class=\"elementor-heading-title elementor-size-default\"><h2>Challenges and solutions<\/h2><\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-fd9359b elementor-widget elementor-widget-text-editor\" data-id=\"fd9359b\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\tWe encountered a number of challenges developing and managing requirements using the approach sketched out here. These were the main ones and some of our solutions:\n<ul>\n \t<li><strong>Latent needs<\/strong>. Users and client stakeholders often don\u2019t know what they want, think they know what they want (but don\u2019t really), want things they assume others will just know&#8230; and it\u2019s your job to elicit these requirements then build stuff that satisfies them. The best way to do this is to ship working software to a representative sample of users in a real-world setting, but since iterations with a full cross-functional teams are expensive, where we could we used rapid prototyping techniques to get useful (though admittedly weaker) feedback early on at a lower cost.<\/li>\n \t<li><strong>Compliance and user input<\/strong>. All interaction with patients and doctors had to be planned, documented, reviewed and approved by compliance (legal, medical and regulatory), so was neither quick nor easy. Whenever we wanted user feedback, we had to produce a discussion guide complete with PDFs of all screens to be shown for review by the relevant local compliance team. This made user interaction during development less frequent than we would have liked, but not impossible. We dealt with this by creating recyclable templates for discussion guides, and building PDF generation into our automated end-to-end test suites, so that production of the assets needed for review was easier on an ongoing basis. This helped accelerate timelines for getting our software in front of users.<\/li>\n \t<li><strong>Enterprise is slow<\/strong>. Everything in enterprise happens slowly. This meant iterative development could be slow, and requirements were often in different states of readiness. A few things helped: (i) an implementation plan sequenced to allow for clarification and validation in areas that needed more time, (ii) working on features that had better developed requirements first; (iii) ensuring we bore no risk for parts of the process we didn\u2019t control.<\/li>\n \t<li><strong>Enterprise isn\u2019t agile<\/strong>. Enterprises aren\u2019t usually agile, and healthcare enterprises certainly aren\u2019t. Our project lead, however, was attracted to new ways of working, so we embedded client review and feedback at a global level into the showcases at the end of every sprint (more frequent interaction\/decision making was unrealistic). This worked well to elicit additional client requirements throughout the project. The main challenge was going through compliance reviews before launch, which was a local process done on a (near) final asset and not set up to work iteratively, which meant interaction, and must-have requirements, came late in the cycle. This process was unchangeable, so really the only solution available to us was building contingency into the delivery schedule. This contingency turned out to be insufficient, though we were able to trigger a contractual extension that allowed us to minimise financial downside for us, at least.<\/li>\n \t<li><strong>Lots and lots (and lots) of stakeholders<\/strong>. Eliciting requirements from lots of stakeholders spread over the globe was impractical for a small team with limited resources. We solved this by creating a core team at a global level whose job it was to represent the requirements of stakeholders across the business and facilitate contact with them, where necessary. We who had scheduled touch points with our team and process. This worked pretty well in many areas, but of course wasn\u2019t perfect, the main area requiring additional work being compliance, which was quite different across localities.<\/li>\n \t<li><strong>User stories or use cases<\/strong>? User stories provided us with a concise way of describing a user need, and could be understood by stakeholders. They also have disadvantages, many of which are highlighted by Alistair Cockburn in\u00a0<a href=\"http:\/\/www.inf.puc-rio.br\/~ivan\/INF1013\/NotasAula\/Why%20I%20Still%20Use%20Use%20Cases.pdf\" rel=\"noopener\">a great piece<\/a>\u00a0on the limitations of user stories vs. use cases, namely lack of (i) context for designers, (ii) completeness for dev teams and (iii) granularity for planning\/research. Whilst use cases can fill these gaps, they are also harder to write and more difficult for stakeholders to understand. We decided to combine elements from each &#8211; user stories with acceptance criteria formed the core, supplemented with acceptance criteria for alternate goals (like extension points) and UML diagrams (e.g. using PlantUML\u2019s human-readable syntax rather than XML) to provide context for technical design and granularity for timely assessment.<\/li>\n \t<li><strong>Scope creep<\/strong>. This happens on all projects. Naturally we built contingency buffers in for this, which provided some leeway for scope increases within budget. On this particular project, a lot of the scope creep came from local compliance teams, particularly in countries with more onerous requirements e.g. the UK and Canada. Since these requirements were often handed to us in the form of solutions \u2014 which frequently conflicted with what had been implemented to satisfy patients or doctors \u2014 we first spent time identifying the underlying requirements, then worked out how to satisfy them in a way that was consistent with other user requirements. Sometimes this was possible, other times it was not, and compliance won the day.<\/li>\n<\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-6f0eac8 elementor-widget elementor-widget-heading\" data-id=\"6f0eac8\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"heading.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t<h2 class=\"elementor-heading-title elementor-size-default\"><h2>Summing up<\/h2><\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-8b03533 elementor-widget elementor-widget-text-editor\" data-id=\"8b03533\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\tThough much of what you read online about requirements development suggests approaches are polarised between\u00a0<em>Analysis paralysis<\/em>\u00a0and\u00a0<em>Iteration worship<\/em>\u00a0\u2013 and most people are aligned to the latter \u2013 there are intermediate approaches that can yield real benefits quickly.\n\nFor my money, the most material benefits of an intermediate approach like the one described here are improved velocity, cash burn and team morale as a result of improved decision making due to better context. From personal experience, I have watched our team\u2019s velocity improve by ~40% as a result of spending time thinking about and defining requirements properly.\n\nThis &#8220;objective&#8221; measure comes with some caveats &#8211; it it is calculated crudely by measuring the difference between average story points completed per sprint for a defined period pre and post introduction of better requirements development, and it fails to control for other confounding variables (e.g. personnel changes).\n\nBut directionally it\u2019s interesting, and the fact it was also accompanied by a dramatic improvement in subjective measures &#8211; team morale and satisfaction with progress made during sprints &#8211; provides some additional evidence.\n\nIn summary, the ROI on that initial investment of time and effort is material and the payback period can be as short as a single sprint, so it is definitely worth doing.\n\nWhat would I do differently next time? Short of coming up with a magic way of making compliance functions totally agile and fully integrated with the development cycle, the top things I would do are:\n<ul>\n \t<li>Come up with acceptable ways of involving local compliance teams earlier in the development cycle e.g. by involving more of them with prototype review to flush out relevant requirements earlier<\/li>\n \t<li>Figure out how to capture non-functional requirements in a more consistent and measurable way, looking at formalisms like\u00a0<a href=\"http:\/\/understandingrequirements.com\/resources\/2.23%20%20Quantifying%20Quality%20Requirements.pdf\" rel=\"noopener\">Planguage<\/a>\u00a0for inspiration<\/li>\n \t<li>Use a different toolchain to manage requirements &#8211; using a combo of Jira and static sites for docs had a number of problems that I\u2019ll cover in my next post.<\/li>\n<\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-cdd9fcb elementor-widget elementor-widget-heading\" data-id=\"cdd9fcb\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"heading.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t<h2 class=\"elementor-heading-title elementor-size-default\"><h2>What\u2019s next<\/h2><\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-f237c56 elementor-widget elementor-widget-text-editor\" data-id=\"f237c56\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\tPart 3 focuses on tools for managing requirements. It includes an analysis and evaluation of tools we\u2019ve used in the past, and that other modern software teams tend to know about and consider when deciding how to manage their requirements.\n<h2>Bibliography<\/h2>\n<ul>\n \t<li>A. Cockburn,\u00a0<em>Writing Effective Use Cases<\/em>, Addison-Wesley Professional, 2000<\/li>\n \t<li>A. Cockburn,\u00a0<a href=\"http:\/\/www.inf.puc-rio.br\/~ivan\/INF1013\/NotasAula\/Why%20I%20Still%20Use%20Use%20Cases.pdf\" rel=\"noopener\"><em>Why I Still Use Use Cases<\/em><\/a>, 2008<\/li>\n \t<li>D. Gause &amp; G. Weinberg,\u00a0<em>Exploring Requirements: Quality Before Design<\/em>, Dorset House Publishing Company, Incorporated, 1989<\/li>\n \t<li>D. Leffingwell,\u00a0<em>Agile Software Requirements<\/em>, Addison Wesley, 2010<\/li>\n \t<li>G.Moore, Crossing the Chasm, 3rd Edition, Harper Business, 2014<\/li>\n \t<li>K. Wiegers &amp; J. Beatty,\u00a0<em>Software Requirements<\/em>, 3rd Edition, Microsoft Press, 2013<\/li>\n<\/ul>\nA special thanks to Karl Wiegers for his helpful review comments!\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t<\/div>\n\t\t","protected":false},"excerpt":{"rendered":"<p>This post looks at the requirements development process and its outputs on a real-world project. There is an approach for developing requirements that is easy enough to implement and better at delivering value to users and stakeholders. The ROI on the initial investment of time and effort is material and the payback period can be as short as a single sprint, so it is definitely worth doing. Use a different toolchain to manage requirements.&nbsp;<\/p>\n","protected":false},"author":716,"featured_media":3498,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"content-type":"","footnotes":""},"categories":[187],"tags":[95],"ppma_author":[3539],"class_list":["post-2221","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-bigdata-cloud","tag-big-data-amp-technology"],"authors":[{"term_id":3539,"user_id":716,"is_guest":0,"slug":"matt-hartley","display_name":"Matt Hartley","avatar_url":"https:\/\/secure.gravatar.com\/avatar\/?s=96&d=mm&r=g","user_url":"","last_name":"Hartley","first_name":"Matt","job_title":"","description":"Matt Hartley is Co-Founder at Healthforge. He has worked in health tech for a number of years. He is currently working on a new SaaS tool to improve how teams in a variety of sectors document their work, including how they manage software requirements."}],"_links":{"self":[{"href":"https:\/\/www.experfy.com\/blog\/wp-json\/wp\/v2\/posts\/2221","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.experfy.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.experfy.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.experfy.com\/blog\/wp-json\/wp\/v2\/users\/716"}],"replies":[{"embeddable":true,"href":"https:\/\/www.experfy.com\/blog\/wp-json\/wp\/v2\/comments?post=2221"}],"version-history":[{"count":6,"href":"https:\/\/www.experfy.com\/blog\/wp-json\/wp\/v2\/posts\/2221\/revisions"}],"predecessor-version":[{"id":35601,"href":"https:\/\/www.experfy.com\/blog\/wp-json\/wp\/v2\/posts\/2221\/revisions\/35601"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.experfy.com\/blog\/wp-json\/wp\/v2\/media\/3498"}],"wp:attachment":[{"href":"https:\/\/www.experfy.com\/blog\/wp-json\/wp\/v2\/media?parent=2221"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.experfy.com\/blog\/wp-json\/wp\/v2\/categories?post=2221"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.experfy.com\/blog\/wp-json\/wp\/v2\/tags?post=2221"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.experfy.com\/blog\/wp-json\/wp\/v2\/ppma_author?post=2221"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}