Non Functional Requirements
Delivering well received and successful systems and products starts with high quality requirements. It is often said that the “Customer is king” in project management circles and that is certainly true when capturing requirements so it is essential that time spent with the customer is not wasted and that requirements are elicited without losing their attention. It is important to take the customer through a process of requirements capture and agreement that leads to a successful outcome both for the customer and the supplier.
PSL has a lot of experience in capturing, analysing and managing requirements. We can help you and your project deliver successfully. Here is a sample of our experience: -
Capturing requirements is not just about listening to the ‘request’ (as perhaps a sales person might take an order), but also about ensuring that the right questions are asked and answered somehow. In most cases the customer will know all about the ‘functionality’ of the desired solution and assume that you know all about the non functionals. Unfortunately its the non functional requirements that dicate the quality and can make a delivery fail if not addressed. It is important to cover all requirements aspects across, business, customer and end user. The following illustrates a sample of the topic areas to be covered: -
Business needs and objectives
Questions such as: -
- What is in the business case?
- Are there indentified cost objectives?
- When is the solution required to ‘break even’?
- How is the delivery conceived – will there be a pilot?
- In what sort of ‘infrastructure’ does the solution have to operate?
- Is it intended to outsource supply?
- How is intended to operate the solution?
- Is the solution part of a process automation initiative?
- What are the process availability requirements?
- Is there critical or sensitive information to be stored?
- What are the critical success factors?
End user expectations
Questions such as: -
- Is this a new system/solution? (Is there a prejudice to overcome?)
- Does this support a new or revised business process?
- What training is planned and will a training system and data be required?
- How many users and a host of other quantitative questions needed to dimension the solution?
- Is there a maximum response time for the process to work? (e.g. Queuing times or data acquisition times?)
- What support is required? (Is there an existing support infrastructure?)
- Do users expect the system to be available 24/7/365?
Technical perspective and constraints
Questions such as: -
- Is there a technical architecture? (e.g. predefined 3rd party products list)
- Are there data centres to be used.
- What are the operational constraints? (e.g. Are there prerequisites for installation, upgrade and support?)
- Is outsourcing of operations and support planned?
- What are the data back up and archive requirements?
- Is the system/solution part planned to be part of a disaster recovery plan? (e.g. Is there a Recovery Time Objective?)
- Are there network issues in the infrastructure that the solution will have to accommodate? (e.g. Is there a network budget?)
Unfortunately it is not just a case of creating some challenging questions and sending out a questionnaire. The real skill in getting answers to questions is in the hands of the requirements consultant and the way the interview is conducted.
If you would like to know if PSL can help you with non functional requirements please complete this enquiry form.
Requirements Management and Delivery
Having created a set of requirements it is then important to ensure that they are properly analysed, sorted, prioritised and scoped into a design. There is plenty of standard text book theory to be had on this topic as well as a number of requirements management tools. So assuming we have the basics covered such as ambiguity, identification, classification and documentation PSL can help you with managing those requirements through to delivery.
Requirements Model
(Note some of the terms used below refer to ‘Phases’ and ‘Outcomes’ described in ISO 15288 – “Systems Engineering – Systems Lifecycle Processes” © British Standards Institute)
During analysis the requirements should get broken down into atomic statements that can be attributed to one of more sources and ‘stakeholders’. i.e. Who wants and who is prepared to pay for it. Other information references may be associated with these requirements such as documents, standards and estimates. As the analysis, design and implementation takes place (‘Concept and Development Phases’) it is essential to keep track of the requirements, as the various work packages create their ‘end products’
In fact throughout the lifecycle ‘Requirements Traceability’ is essential to assure the required quality of the solution. Once the thread from requirements to activities and ‘end products ‘ is lost control over quality is also lost and very hard to re-gain. The why? when? what? cannot be effectively assured by the ‘Production’ and ‘Utilisation Phases ’.
Significant benefit can be obtained by creating a model of the requirements in the context of the ‘end products’. Besides the requirements and associated entities the model will contain other objects such as scopes, (bundles of requirements to be delivered as a release), system components identified by design, use cases, test cases, faults and deliveries (versions).
By realising this model as a database and populating it as work progresses many of the documentation end products can be created as reports. Queries on the database can then provide these views (amoungst many) to enable control: -
- Requirements in scope
- Requirements delivered
- Requirements with faults
- Cost of requirements
- Test coverage against requirements
If you would like to know if PSL can help you with requirements management please complete this enquiry form.
