I’ve been getting a lot of questions about requirements and how to document them, so I decided to dedicate this week to requirements. Oh, the joys of requirements. It isn’t just using your colleagues and your expertise to come up with the requirements that will be used to design the envisioned system. You have to especially ensure that you understand what stakeholders and users want as well.
This is what makes requirements so complicated and fun (yes, I have warped sense of what is fun). It isn’t just one group that you have to think of. You usually have to think of multiple ones. However, if you take your time to do it right, keep the communication channels flowing, and don’t let your ego get in the way, you can collect and analyze requirements with ease. I’m going to start with user requirements because users are always the ones you want to think of first. Also, this is the highest level of requirements.
What are user requirements?
The easiest way to explain user requirements is to say that the these are the requirements that detail how the end-user expects the system to behave. Even though this sounds easy, it is probably the hardest requirements to collect. The reason is that you are relying on users to explain their wants and needs. As you probably already know, a person telling another what they want is not the easiest thing to do. If you aren’t able to collect everything that they need, then you are the one who will be held responsible. You can’t blame the users for not giving you what you needed. Spending time figuring out user requirements is also important to specify scope, scheduling, and cost. You will get many “nice-to-have” requests. You have to analyze what users really need, so that you don’t have any issues later.
How do I collect user requirements?
To collect user requirements, you have to spend time with the users while they are using the current system that they have in place. I want to clarify that when I say “current system,” this doesn’t always mean an actual software. This can be manual processes that they are expecting for you to automate. Usually, these are multiple meetings that you will have with representatives of the different user groups. There are times that a client will only want the main stakeholders (e.g. directors, managers, etc.) in the meetings. You have to get them to understand that you have to speak to the people who really use the system. They are the ones who will be the ones to tell you if you are headed in the right direction; not the people who are in charge but don’t have anything to do with the system.
What kind of documentation should I ask the client to provide?
All of it! Even if it seems redundant, ask for it. You want to get flow diagrams, organizational charts, reports, user manuals, and anything else that you need to understand what the users wants and need.
What else can I do to get user requirements?
You really want to sit down with the different user groups, and see how they use the system. This will allow you the chance to ask them all the questions you need answered. There are times that users will go off on a tangent. You will have to learn the art of being tactful and getting them back on track. Believe me, you don’t want to waste any time.
After you have collected all the user requirements, you want to show stakeholders and users what you have come up with. A Requirements Document or Requirements Specifications is the document to do just that. It’s a good practice to start adopting because you can have them sign off on the collected requirements. If they come later with new requirements, you have the requirements document that they accepted. Believe me, it usually happens, so you want to ensure that you cover your tracks. This is the great thing about documentation.
What should be in the document?
In the document, you want to cover the following areas:
- The current system
- User characteristics
- Functional requirements
- Non-functional requirements
Tomorrow, I will talk about assumptions, constraints, and dependencies.