User Requirements, Functional and Non-Functional Requirements
0 likes659 views
The document outlines a comprehensive approach to user requirements development, detailing the types of requirements needed for software projects, including business, stakeholder, solution, functional, and non-functional requirements. It emphasizes the importance of stakeholder involvement, user stories, and acceptance criteria in validating user requirements and provides various techniques for eliciting, analyzing, and documenting these requirements, such as use cases, job stories, and work breakdown structures. Additionally, it highlights the significance of non-functional requirements, which pertain to the quality attributes of the system, and offers guidance on their elicitation and analysis.
![Functional &
Non-Functional Requirements 📗
Functional requirements describe what the product should do, while non-functional requirements
place constraints on how the product should do it. They can be expressed in the following form:
• Functional requirement: "The system must do [requirement]."
• Non-functional requirement: "The system shall be [requirement]."
Examples:
• Functional requirement: "The system must allow the user to submit feedback through a contact
form in the app."
• Non-functional requirement: "When the submit button is pressed, the confirmation screen must
load within 2 seconds."](https://image.slidesharecdn.com/userrequirementsfunctionalnonfunctionalrequirements-230103074010-95f1198b/85/User-Requirements-Functional-and-Non-Functional-Requirements-12-320.jpg)
![User Story is based on User Personas & Assumptions
User Story – focuses on functions and solutions. Situation context, user
motivation and anxieties are ignored. Explains Who users are (roles and
atributes) and What they do (actions) but may miss Why they do...
As a [user persona], I want to [user action], So that [action outcome].
Too many assumptions
Who? - May be irrelevant
What? - Are we sure this is
the best action to do... Expected result
Source: Adapted from Jobs-to-be-done book by Intercom](https://image.slidesharecdn.com/userrequirementsfunctionalnonfunctionalrequirements-230103074010-95f1198b/85/User-Requirements-Functional-and-Non-Functional-Requirements-23-320.jpg)
![Job Story focused on Context & Motivation
Job story focuses on the triggering event or situation, the
motivation and goal, and the intended outcome.
Job Stories can only come from real customer interviews.
When [trigger], I want to [goal], So I can [desired outcome].
Situation or Event User motivation Expected result
Source: Adapted from Jobs-to-be-done book by Intercom](https://image.slidesharecdn.com/userrequirementsfunctionalnonfunctionalrequirements-230103074010-95f1198b/85/User-Requirements-Functional-and-Non-Functional-Requirements-24-320.jpg)
User Requirements, Functional and Non-Functional Requirements
- 2. A typical requirements capturing process encompasses four elements
- 5. Business Requirements Requirements for software development project: BABOK 2.3. Requirements Classification Schema Stakeholders / Users Requirements Solution Requirements Transition Requirements WHY? High-level statements detailing goals, objectives, and needs, that describe why a change has been initiated at enterprise, a business area, or a specific initiative level. WHO? The needs of stakeholders (can be conflicting) to be fulfilled to achieve the business requirements. - Customer - End-Users - SME (Experts) - Regulators - Sponsors - Suppliers - Testers - and others... HOW? Detailed capabilities and qualities of a solution that meets stakeholders' requirements Functional – functionality behavior requirements Non-functional – functionality quality requirements These requirements are temporary in nature: - capabilities that the solution must have and - conditions the solution must meet to facilitate the transition from the current state to the future state.
- 6. User Requirements 📗 The needs of discretestakeholder groups (top-level managers, nonmanagement staff, customers,etc.) are specified to define what they expect from a particular solution.This requirements group serves as a bridge between the generalized business requirementsand specific solution requirements. Stakeholder requirements: describe the needs of stakeholders that must be met to achieve the business requirements.They may serve as a bridge between business and solution requirements(BABOK). User requirements cover the different goals end-users can achieve using the product and are commonly documentedin the form of user stories, use cases, and scenarios.
- 7. User Requirements in Waterfall 📗 The user requirement(s) document (URD) or user requirement(s) specification (URS) is a document usually used in software engineering that specifies what the user expects the software to be able to do. Once the required information is completely gathered it is documented in a URD, which is meant to spell out exactly what the software must do and becomes part of the contractual agreement. A customer cannot demand features not in the URD, while the developer cannot claim the product is ready if it does not meet an item of the URD. The URD can be used as a guide for planning costs, timetables, milestones, testing, etc. The explicit nature of the URD allows customers to show it to various stakeholders to make sure all necessary features are described.
- 8. User Requirements 📗 • Stakeholder involvement is essential for validating the user requirements.Are these the correct user requirements? • Elicitation techniquesenables the discovery and understandingof the needed requirementsby the users. • Analyze and comparealternative requirementsand their cost impacts on the project. • Traceabilityof user requirements is critical.Support documentation,and link those to solution-level requirements.
- 9. Functional & Non-Functional Requirements Mark Opanasiuk Senior Business Analyst @ EPAM Kyiv, 2022
- 10. Solution Requirements Functional Requirements Functional requirements: describe the capabilities that a solution must have in terms of the behavior and information that the solution will manage Non-Functional Requirements Non-functional requirements or quality of service requirements: do not relate directly to the behavior of functionality of the solution, but rather describe conditions under which a solution must remain effective or qualities that a solution must have
- 12. Functional & Non-Functional Requirements 📗 Functional requirements describe what the product should do, while non-functional requirements place constraints on how the product should do it. They can be expressed in the following form: • Functional requirement: "The system must do [requirement]." • Non-functional requirement: "The system shall be [requirement]." Examples: • Functional requirement: "The system must allow the user to submit feedback through a contact form in the app." • Non-functional requirement: "When the submit button is pressed, the confirmation screen must load within 2 seconds."
- 13. Functional Requirements 📗 Functionalrequirements are product featuresor functionsthat developers must implement to enable users to accomplish their tasks.So, it’s important to make them clear both for the development team and the stakeholders.Generally,functional requirementsdescribe system behavior under specific conditions. For example: The system sends an approval request after the user enters personal information. A search feature allows a user to hunt among various invoicesif they want to credit an issued invoice. The system sends a confirmationemail when a new user accountis created.
- 14. Functional Requirements Classifications 📗 We can group them based on the functions a featuremust perform in the product,for example: Authentication Authorization levels Compliance to laws or regulations External interfaces Transaction processing Reporting Business rules, etc.
- 15. Requirements Documents Formats 📗 Most common formats and documents: Software RequirementsSpecification (SRS) document Use cases User stories Work Breakdown Structure(WBS), or functional decomposition Prototypes Models and diagrams
- 16. SRS📗 Both functionaland nonfunctionalrequirements can be formalized in the software requirements specification(SRS) document. SRS must includethe following sections: Purpose.Definitions,system overview, and background; Overall description.Assumptions,constraints,business rules, and product vision; Specific requirements. System attributes,functional requirements,and database requirements. The SRS can be a single documentcommunicatingfunctionalrequirements or it may accompany other software documentation like user stories and use cases. Goal: to document requirementsfor every single feature before buildingit!!!
- 17. Use Cases📗 Use cases describe the interaction between the system and external users that leads to achieving particular goals. Each use case includes three main elements: Actors. These are the external users that interact with the system. System. The system is described by functional requirements that define an intended behavior of the product. Goals. The purposes of the interaction between the users and the system are outlined as goals. There are two formats to represent use cases: Use case specification structured in textual format Use case diagram
- 18. Use Case Specification Example
- 19. Use Case Diagram
- 20. User Stories📗 A user story is a documented description of a software feature seen from the end-user perspective. The user story describes what exactly the user wants the system to do. In Agile projects, user stories are organized in a backlog, which is an ordered list of product functions. Currently, user stories are the most popular format for backlog items. User stories must be accompanied by acceptance criteria. These are the conditions that the product must satisfy to be accepted by a user, stakeholders, or a product owner. Effective acceptance criteria must be testable, concise, and completely understood by all team members and stakeholders. They can be written as checklists, plain text, or by using Given/When/Then format. Contrary to a popular misconception, functional requirements are not analogous to user stories, but stories can be a useful tool for deriving requirements with the user in mind.
- 21. User Stories📗 All user stories must fit the INVEST quality model: I – Independent for separate work N – Negotiable for detalization during development V – Valuable for customer E – Estimable to schedule and prioritize implementation S – Small enough to be done within sprint T – Testable to ensure that requirementsare done
- 22. User Stories📗 • User story: As an existing user, I want to be able to log into my account. • Functional requirements: • The system must allow users to log into their account by entering their email and password. • The system must allow users to log in with their Google accounts. • The system must allow users to reset their password by clicking on "I forgot my password" and receiving a link to their verified email address.
- 23. User Story is based on User Personas & Assumptions User Story – focuses on functions and solutions. Situation context, user motivation and anxieties are ignored. Explains Who users are (roles and atributes) and What they do (actions) but may miss Why they do... As a [user persona], I want to [user action], So that [action outcome]. Too many assumptions Who? - May be irrelevant What? - Are we sure this is the best action to do... Expected result Source: Adapted from Jobs-to-be-done book by Intercom
- 24. Job Story focused on Context & Motivation Job story focuses on the triggering event or situation, the motivation and goal, and the intended outcome. Job Stories can only come from real customer interviews. When [trigger], I want to [goal], So I can [desired outcome]. Situation or Event User motivation Expected result Source: Adapted from Jobs-to-be-done book by Intercom
- 25. User Story vs. Job Story USER STORY (focuses on user persona and solution) JOB STORY (discoveredfrom users' experience) WHO: As a user of news app connected to wi-fi, WHAT: I want to save in cache memory 50 recentnews articlesfrom the news feed, OUTCOME:So I can access and read those later. Questions: But does user really want this? Why 50 articles? Why is it importantfor user to read those later?Do we need to refresh the cashednews when user has accessto the internet? SITUATION: When I am not connected to free wi-fi, GOALS:I want to be able to read recent news for free AND have access to those news even offline, OUTCOMES:So I will save money on expensive mobile traffic AND stayinformed on recent news. Provides more context,gives more space to think aboutthe best solution to be detailed in designs and tasks . Solutionssuggested: cache recentnews in app when connectedtoWi-Fi + publish news as FBInstantArticles on our FB page (FB trafic is free in many African countries) Jobs stories slightly revise the format to be less prescriptive of a user action, and thereby give more meaningful information for the designer and developer to buildfor the user’s expected outcome.
- 26. Functional decomposition or Work Breakdown Structures (WBS)📗 WBS is a visual document that illustrates how complex processes break down into their simpler components.WBS is an effectiveapproach to allow for an independent analysis of each part. WBS also helps capture the full pictureof the project. • Find the most general function. • Find the closest sub function. • Find the next level of sub function. • Check your diagram. High Level Function->Sub-function -> Process -> Activity
- 27. Functional decomposition or Work Breakdown Structures (WBS)
- 28. Software prototypes📗 Software prototype is an umbrella term for different forms of early-stage deliverables that are built to showcase how requirements must be implemented. Prototypes help bridge the vision gaps and let stakeholders and teams clarify complicated areas of products in development. Prototypes can be cheap and fast visual representations of requirements (throwaway prototypes) or more complex ones (evolutionary prototypes) that can even become MVPs. Wireframes - a two-dimensional illustration of an interface that specifically focuses on space allocation and prioritization of content, functionalities available, and intended behaviors. Mockups - detailed visual designs that convey the look and feel of the final product. Prototypes - allow for some interface interactions, like scrolling, clicking on links, or filling in forms
- 30. Non-Functional Requirements 🛠️ (NFR) Non-FunctionalRequirements(NFR) - Non-functional requirements(also known as quality attributesor quality of service requirements)are often associated with system solutions,but they also apply more broadly to both process and people aspects of solutions.They augment the functional requirementsof a solution,identify constraintson those requirements,or describe quality attributesa solution must exhibit when based on those functional requirements. Non-functional requirementsanalysis examines the requirementsfor a solution that defines how well the functional requirementsmust perform. It specifies criteriathat can be used to judge the operation of a system rather than specific behaviors (which are referred to as the functional requirements). BABOK 10.30.Non-Functional Requirements Analysis
- 31. NFRs are a huge requirements domain 🎯 Often referred as the "-ility" requirements 1. Usability 2. Availability 3. Reliability 4. Scalability 5. But there are so many more such as...
- 33. NFRs - Usability Usability defines how difficult it will be for a user to learn and operate the system. Usability can be assessed from different points of view: Efficiency of use: the average time it takes to accomplish a user’s goals, how many tasks a user can complete without any help, the number of transactions completed without errors, etc. Intuitiveness: how simple it is to understand the interface, buttons, headings, etc. Low perceived workload: how many attempts users need to accomplish a particular task. Usability requirements may include also language barriers and accessibility requirements: People with no understanding of French must be able to use the product.
- 34. NFRs - Usability Ease with which a user can learn to use the solution (BABOK). - Who are target users? - What is the usage context? - What are the most frequentlyperformed tasks? - What is the optimal time for each task? - What is the longest acceptable time for each task or wait time between steps? - What are the alternative flows for each task? - What is the tolerance for user navigation errors? - How do we define and measure user satisfaction?
- 35. NFRs - Availability Degree to which the solution is operable and accessiblewhen required for use, often expressed as 100% minus the percentage of time a system/solution is unavailable (BABOK). - When the system is down, or sluggish, what does this mean to our customer? - When a user has an active session, and the DB or application goes down, how is the user or our reputation is affected? - What is our system unavailability tolerance? - Is this function critical to the customer, business, or technical team? Do any other systems rely on this function/service/module output? - If a certain module becomes unavailable, how does it affect the system's availability? - What is our tolerance for system goes down for the scheduled maintenance? Example: New module deployment mustn’t impact front page, product pages, and check out pages availability and mustn’t take longer than one hour.
- 37. NFRs - Reliability Reliability defines how likely it is for the softwareto work withoutfailure for a given period of time. Reliabilitydecreases because of bugs in the code, hardware failures,or problems with other system components. To measure software reliability,you can count the percentage of operations that are completed correctlyor track the average period of time the system runs before failing. Example: The database update process must roll back all related updates when any update fails.
- 38. NFRs - Scalability Degree with which a solutioncan grow or evolve to handle increased amounts of work (BABOK). - What is the projected user growth over the system lifetime? - What is the projected resource use per user over lifetime of the system? - How large data sets we operate? How large is user's data set? - What is the demand for CPU / how many calls per second under normal working conditions? - What would be considered a heavy load for the system in terms of users / data / requests? - How shall system react in case of increasing load? What is our plan? - What monitors can we put in place to track load and get alerts on high loads? Example: The website attendance limit must be scalable enough to support 200,000 users ata time.
- 39. NFRs - Performance Degree to which a solution or component performs its designated functions with minimum consumption of resources. Can be defined based on the context or period,such as high-peak, midpeak or off-peak usage (BABOK).Includes short response time,high processing rate,low CPU utilization,etc. - What shall be the request timeout? What shall happen if a user does not receive a response within X seconds? - What are the time constraints for the user performing the task? - What is the current actual response time for our customers? - What other systems may impact the performance of our system? How to mitigate those? - How many transactions per second shall the system be able to handle in normal and peak usage times? Example: The front-page load time must be no more than 2 seconds for users that access the website using an LTE mobile connection.
- 40. NFRs - Security Securityrequirements ensurethat the softwareis protected fromunauthorizedaccess to the system and its stored data. It considers different levels of authorization and authentication across different users roles. For instance,data privacy is a securitycharacteristicthat describes who can create,see, copy, change,or delete information. Securityalso includesprotection against viruses and malware attacks. - What user's role / permissions/ other securitycharacteristicsare required? - What levels of authorization and authentication across different users roles are required? Example: Access permissions for the particular system information may only be changed by the system’s data administrator.
- 41. NFRs elicitation🛠️ 1. Do your research before addressing NFRs, Plan elicitation ahead to frame NFRs well for the business, send questions in advance before meetings. 2. Bring together stakeholders (such as operations and support). 3. Scenario based elicitation: What if..., GWT technique, Drill down techniques (5Whys, root cause, decomposing into smaller pieces). 4. Define NFRs by interpreting them into business relatable ideas. 5. Find a NFRs champion among developers in your team.
- 42. Thank you! Q&A Mark Opanasiuk Let's connect on LinkedIn TG channel: @wtf_is_pmf Medium: @markopanasiuk