PRJ845 Week 2. Functional Requirements
Writing Functional and Non-Functional Requirements
“Functional and Non-Functional Requirements” document usually is the first technical document to answer the question “What is to be developed?”
The “End Users” section contains the list of end users who should be provided with relevant functionality.
Note. The term “System” in this document means the final product end user interacts with.
The “Functional Requirements” section gives the description of applicable functions for each Actor who is an end user. The description includes general information and detailed scenarios of 3 types:
- Main Success Scenario – to describe the actions/steps that occur under the regular circumstances to achieve major business goal
- Extension Scenario – to describe branching actions that appear as the result of end user’s actions
- Exception Scenario – to describe actions to handle error situations that appear on technology reasons
The “Non-Functional Requirements” section describes any other applicable requirements that cannot be expressed through functional description. The most often it includes:
- Security
- Availability
- Reliability
- Performance and Scalability
- Usability
Tips for Writing Functional Requirements
Usually this document is used to confirm the system functionality with the customer. Customers are not technical, so they cannot understand technical terminology. The document must provide good understanding of what end users will be capable to do and what capacity will be provided by the system to facilitate their activity.
Make the list of End Users
End users usually are presented by their roles in business activity, such as Customer, Retailer, etc. Nowadays systems provide web based interface not only to those who extract business value from the system, but also for supporting personal. Thus, administrators also can appear in the list of end users.
Make the list of Functions
The list of functions gives a reader general idea about this particular software component functionality. Usually it is of a general character and includes only major functions without details.
Describe Work Flow – Main success scenario
The scenarios describe the actions flow between end users, one or many, and computer system, or simply system. At this stage we do not consider the system structure, we simply think about it as the whole, designed to respond end users’ requests or actions. We also assume the data is the part of the system.
Start and End points (users and data) are defined. Now is the time to define the actions that take place between these two points (scenario, in other words). The actions included into the workflow should in fact outline the way to transform data from its state at Start Point to the state of End Point.
This transformation may require other data involved. For example you may have to extract data from the database, to show it on the screen, to obtain user’s choice, to do some processing and finally to construct data needed at End Point. This stream may not be straight forwarded. Exact values of data provided may drive to branching in your scenario. However we always expect some successful way that brings positive result: User is registered, PO is created, Invoice is sent etc. The sequence of events on this successful way is known as “Main success scenario”.
Describe main success scenario step by step to show what is to be done. First of all consider events implemented by a user. Focus on data and on indicate the actions required at the moment. Use the words like:
- User indicates that he wants to do registration
- System provides the screen with personal data fields
- User inputs the data
- User submits the data input
- System gets the data
……..
Be as specific as possible on this stage but without technical details.
Describe Workflow – Extension scenario
On the road, along the main success scenario some particular data values make changes in the workflows. Example: for Users Login it is expected to obtain valid ID and Password from a user. However it may happen that at least one of them is not correct. Such situations must not be abandoned. The system must contain the relevant software modules; therefore the logic (scenario) of branching must be described. They are known as Extension (or Alternative) Scenario.
Describe Extension Scenario starting from the point of branching
Describe Work Flow – Exception Scenario
Branching described with extension scenarios has been caused by a user’s legitimate actions. User has the right to be mistaken in data input. However the regular activity may be interrupted because of the system’s mistaken behaviour. Examples: RDB is not accessible because of the connection broken, Java module throws the error message. Again the computer system must be prepared for such a problem. Usually the system cannot fix them, but at least they should be intercepted, logged and error message is to be sent to a user. Special logic (scenario) is required to describe the system behaviour. They are known as Exception Scenario.
Describe exception scenario without details. Simply identify potential problems and what will appear.
Note. The number of roles, main success, extension or exception scenarios is not limited in any way.