Dawn
Nothing like an e-mail asking you if you did something to remind you that you haven’t done it yet! I was asked to write a blog on writing requirements about a month ago. The same time I was assigned to a project requiring me to write requirements. Therefore I hadn’t written my blog until I got the e-mail, from our blog manager, asking about it. Since I am currently completely immersed in writing requirements, it probably is a good idea for me to sit back and think about why these lines of information are so critical.
Requirements and their relevance
Before a system can be built, upgraded or enhanced, you need to figure out what it is going to do and how it is going to do it, which is not as easy as it sounds. There are two types of requirements: system requirements that deal with the server size or what platform to use, data migrations etc.—you know the technical stuff—and the workflow requirements that outline how the data will move through the system. Both types are integral when building, redesigning, updating, or customizing any system.
Requirements and their challenge
Requirements of either type are not for the faint of heart. You need to be able to look at the system as a whole and also be able to see all the individual workflows, all at the same time. You need to have a good working relationship with the system users, or the people who will eventfully be required to use the system for which you are writing the requirements. Oh yeah, there is also documenting everything thoroughly so that the programmer who is actually building the system understands what the system needs to do, at that given moment.
My take on requirements
Though I have some experience with technical requirements, I usually write workflow requirements. Workflow requirements refer to how the system will move the data and how the data will be accessed by the user. When writing workflow requirements, you need to think about what goal the system is trying to achieve at a given moment: “Do you want to access the data?”, “When do you enter a new data element?”, or “How is the data then going to be used?” Then you need to write it out succinctly so that the programmer can write the code correctly.
Requirements are the starting and ending point for every system. They are the blueprint used to build the system and, once the system is built, they become the standard to test the system ensuring it does what it is supposed to do. If the system shall be capable of X, then the test plan will include verifying the system can do X. The more time spent on the creation and refining of requirements in the beginning of a project, the less time spent on building, testing and fixing the system after it is built.
So now that I have taken a brief break to write about requirements, I will now go back to actually writing them. I know you are so jealous.
Guest Blogger
Bobbie Laur
Sharyn Grove
Jeremy Monn
Raquel Frye
Clay Hickson
Dawn Bott
Lindsey Meyer
Allie Pyzik
Daraius Irani
Past Bloggers
Jenn Lake
Kelsey Beckett
Timothy Brooks
Ashley Buzzeo
Matt Michels
Nicole Schiraldi
[...] I am able to write and help people organize their work lives through SOPs and manuals and create requirements for new systems. Not to mention, I also I have been able to dust off my old forensics skills (i.e., speech and [...]
[...] has many skills and talents and I have highlighted some of them in my past blogs (What Do You Require? and Three Scary Words (Standard Operating Procedures)). But for this blog I thought I would [...]