Most NFRs can be easily logically linked back to the user. Society - the impacts of your project on the world outside of direct user service.Įvery single are and sub-area can be elaborated on much further.Funders - those who are responsible for funding financing the project and their representatives.Workers - in this context I mean anyone who is involved in the development and creation of a product / service.They could be customers, they could be workers within an organisation, they could be citizens using public services. Users - those who will actually use the products or services.You can chop and change how you think about stakeholder groups and get a lot more granular but this set I feel is always relevant. This can’t be exhaustive or perfect but should give you a lot more to think about NFRs and how you are dealing with them in your projects. This can be another great way to split up requirements so they can be organised and addressed more clearly.įor the rest of this post we will consider many of the most common NFRs organised by stakeholder groups. Obviously serving users is very important and perhaps most important (as companies like Apple and Amazon will attest) but every product and project has other stakeholders which have other interests and come with their own NFRs. Core Stakeholder GroupsĪll of the NFR examples provided above are related to users. Being atmospheric (whatever that means) could be the core guiding requirement for this project. Clearly, some NFRs are very clear and some can be harder to pin down and verify. Avoiding crashes is do to with the internal composition of the game whereas being atmospheric needs to be expressed throughout the games user-facing design. Some types of non-functional requirements are addressed as completely separate concerns in isolation and sometimes they are completely woven in to a products function. The game must be accessible for all user segments.The user must experience a strong story.
You will be able to crawl, crouch walk, walk, run and jump.You will be able to customise your character.Randomly made up, high level, each functional requirement would need to be more logically categories and broken down much to be worked upon.
#Functional requirements software
No distinction is perfect but one way is to think about what software must do vs. They may sound secondary but are always very important and often more important. Non-functional requirements must be addressed to enable function. NFRs are frequently referred to as ‘ilities because they include many concerns which end with ility e.g testability.įunctional requirements are the main things that your software must do to solve a problem for users. To do this you need to service a set of needs and wants that people actually have - whether they know it yet or not! Making software - as with making anything - should be about providing value to real people.
Software Quality - Non-Functional Requirements
0 kommentar(er)
