Requirements Engineering
MD
R
MarkdownExample of a: mobile app for a smart home energy management system.
- The technical team typically uses the FRs and NFRs as a basis for creating the software system.
- The business analysts or product owners use User stories and Use Cases to help facilitate communication and understanding between the technical team and other stakeholders
"Technical team can build a software product based on FRs and NFRs"
Order of Artifacts Creation:
- FR (what the system does - high level statements)
- NFR (how well the system does it - characteristics and constraints)
- User Stories (high-level description of a feature)
- Use Cases (detailed description of how a system should behave in response to a specific user interaction or event):
Functional Requirement (FR): The mobile app should allow users to view their current energy usage.
Non-Functional Requirement (NFR): The mobile app should be responsive and load usage data within 5 seconds.
User Story: As a homeowner, I want to be able to see my current energy usage on the mobile app, so that I can track and manage my energy consumption in real time "As a [user], I want to [do something], so that [some benefit or outcome]".
Use Case: When the user opens the mobile app and selects the "Energy Usage" option, the app should retrieve current energy usage data from the smart home energy management system and display it in a clear, easy-to-read format. If the app fails to retrieve the data within 5 seconds, an error message should be displayed indicating that there was a problem retrieving the data. The app should allow the user to refresh the data by pulling down on the screen or tapping a refresh button, and should update the data automatically if the user leaves the app open. "When [some event or trigger] occurs, the system should [do something specific]"
Giving Estimations: Keep an holistic view by combining: [Technology + FR's + NFR's] and [Team Performance + Budget + Timeline]
Created on 3/11/2023