Embedded Files
Solution Requirements
Solution Requirements
Solution requirements are what the client needs from the solution – the features that they want. Solution requirements in a design brief are often worded descriptions rather than technical descriptions.
Functional requirements relate to what the solution should do. Typically, functional requirements will describe a behaviour or function of the software. This includes determining the input required, the desired output, data manipulation and data validation.
Non-functional requirements describe the quality attributes of the solution. This requires consideration of usability, reliability, portability, robustness and maintainability
Solution constraints are factors that may limit or restrict solution requirements. Typically, constraints involve economic, technical, social, legal and usability factors.
Economic
Economic
Economic constraints include time and cost.
The deadline by which the user or client needs to have the solution operational will define the time available to design and develop the solution. The more time available, the more time there is to complete an in-depth analysis and detailed designs, and to develop advanced features of the solution. The shorter the time frame, the faster each stage in the problem-solving methodology needs to be completed.
Meanwhile, the funds available to complete the project may affect the hardware and software (digital systems) available for use, the number and range of staff who are available to work on the solution and even the data used as input, if the required data sets need to be purchased.
Both a lack of time and a lack of money may result in a re-evaluation of the user’s requirements, or a re-evaluation of how those requirements can be achieved.
Technical
Technical
Technical constraints are constraints related to the hardware and software available for the project. Availability and compatability of hardware and software, capacity of storage and equipment, processing speed and security are all examples of technical constraints.
For example, developers need to keep in mind that smartphone users may not always have access to a high-speed network connection, so they need to ensure that any animated data visualisation solution does not require a large amount of bandwidth to download and view.
Social and legal
Non-technical constraints relate to areas other than hardware and software. The user’s level of expertise (social) is an example of a non-technical constraint. For example, if a solution is being developed for users with little digital systems expertise, this may restrict the inclusion of requirements that would involve complex manoeuvres. Creating a solution for a child audience may also restrict the method used to input data into the solution.
Legal requirements are another type of non-technical constraint. Privacy laws may restrict features linked to displaying personal data in the solution, or to collecting data from the device of someone using your solution. Intellectual property laws and ownership of data may also restrict features of a software solution, adding constraints to potential solutions.
SCOPE
SCOPE
The scope outlines the boundaries or parameters of the solution, so that all stakeholders are aware of exactly what the solution will contain. These boundaries or parameters can relate to the entirety of the planned software as a whole, or the contents of a new version of the software. The scope of the solution consists of two elements: what the solution will do and what the solution will not do.
What the solution will do
What the solution will do
What the solution will do is a list of all the solution requirements (both functional and non- functional) that will be included in the solution.
What the solution will not do
What the solution will not do
What the solution will not do is a list of all the solution requirements that will not be included in the solution.
Usually these are solution requirements that were initially sought by the client, but that, because of constraints, have been left out of the solution project.
At the start of the project, outlining what will and will not be included in the solution can help prevent arguments between the client and the developer later in the project.
Page updated
Report abuse