26. Developing a Good User Requirements Specification (URS)

Sometimes users describe a “requirement” but can’t figure out how to “test’ for that requirement. In this case they have described a “wish” and must rethink their description until they can figure out how to test for what they are asking. There must be no “wishes” in a URS. (p. 40)

 

A good User Requirements Specification answers a number of basic questions.

1. What are the work process steps to be computerized? Will these process steps stay the same or are new efficiencies sought with the new system?
2. What are the data and automated flows in the work process that the system must support?
3. How will the new system need to interact with other systems in the work area?
4. Are there specific regulations that apply to the work, the data, or the system itself, e.g. 21 CFR Part 11 or EU GMP Annex 11?
5. What types of data must the system process? Where does data come from? Where does it go?
6. What are the work process user roles and privileges for working with data and using the system?

Note that none of these questions focus on the bits and bytes of technology for the system. This is a requirements specification for computerized support of the user’s work process, not a technical specification for the computer technology itself. Users MUST drive the URS development, NOT the IT staff. Only experienced users in the work process know how the work process really operates and what is actually done with the data. When end users shirk their role for URS development and dump it on the IT department, they will get the system they deserve – great technology with little relevance to the real work to be done and a frustrating work environment.

A standard approach to creating a URS document is to organize related requirements in tables where each requirement has a unique identifier and a work process based description. In order to be a good requirement, there has to be a way to test for it in the delivered system. If the requestor is unable to think of how to do a work-based test for what they want, then the request is a “wish”, but cannot be a “requirement.” Having a column for User Test Topics is essential to ensuring that only real requirements and no wishes get into the URS.

Unique ID	Requirement Title & Description	User Test Topics
SYS.UR.01	SYS secure login with User Name & Password	Use Pos./Neg. Names & Passwords
SYS.UR.02	SYS database needs Audit Trail for edits	Change data & print Audit Trail Report

One or multiple tables can be used to answer each of the six questions asked above. For question one, there may be one main work process or several parallel or sequential work activities with requirements to be described. For question five, large database applications will require focus tables of their own.

The key to a good URS is knowing the work process and its data flows very well, then being creative in thinking how the work process can be used to test the system for the requirements in the URS. In the end, one can add a fourth column to the tables to record the Test Script IDs and this will make an instant Trace Matrix.

 

Next Month: Developing a Good Platform Requirements Specification (PRS)

Separate from the Software Application URS a Platform Requirements Specification (PRS) should be defined. The PRS should consider the users operational requirements, e.g., 24/7 global access by telephony, the software supplier’s technical requirements…and IT operational needs. (p. 153)