What I learned in Req. Engineering
In Requirements Engineering, we learned how to take business asks and turn them into requirements/specifications that can be used to build out a software system or feature set.
Requirements gathering is one of the hardest things to do for any project, software or not.
Customers often don’t know exactly what they want and they don’t know what you can deliver for them. Even if customers do know what they want, communication, and having a shared understanding is really hard to coordinate.
As an attempt to solve this problem, people have applied engineering principles to the practice of requirements gathering, giving us Requirements Engineering.
Biggest Things I learned in Requirements Engineering:
Identify stakeholders, Domain, Constraints, problem to be solved
Have Traceability in your requirements. Traceability is knowing where requirements are implemented in code, and knowing what parts of the code implement certain requirements.
BE SPECIFIC in what the requirement does
Write requirements using the standard format “[system] [MUST/SHALL] [action]”
Goals: overarching themes you want the product to achieve
Requirements: Items you must satisfy in order to achieve the goals. NO IMPLEMENTATION DETAILS HERE
Specifications: HOW you will implement/design your system to satisfy the requirements
Goals -> requirements (NO DESIGN/implementation)-> system specification
“ly” “ily” = non-functional goals. Translate to functional. VERY HARD
Communicate OFTEN
Iterate on your discussions and requirements - Refine them over several meetings
How this is applicable to my job as a Software Engineer:
As an individual contributor, and someone who is not a project manager, business analyst, or architect, I do not necessarily play a role in receiving customer wishes and turning them into executable specifications. I do, however, get assigned user stories, tasks, and bugs. Often times what I am given to work with is a title explaining the issue and maybe a few lines in the description box. I am left to figure out the rest of the picture.
Once I was given a user story where the title read “metrics for API processing” and the description contained the single line “Implement alarm metrics for the controller”. There is nothing inherently wrong with this information. It describes generally what I will be doing but there is no context given nor any details about exactly what metrics are needed, Perhaps if I was writing this story I might be inclined to fall into the same trap. I might (wrongly) assume that whoever will be working on it will have the same background, understanding, and knowledge about what needs to be done that I do.
This is where Requirements Engineering has been useful to me.
I have reached out to team members, technical leads, and project managers, using the skills I learned in Req. Eng. to get all of the information I need. I know now to ask about constraints, the domain we are operating in, and to specify exactly what the problem is. I can take what knowledge I have gathered and compile it into a concrete list of specific requirements. Armed with the requirements I can see what specifications I can implement to satisfy them. If I’m ever uncertain about a requirement or story changes, I know to iterate over the initial requirements to continuously improve them. Lastly I can evaluate the traceability of the requirement to see if it is working towards the overall goal or if it is unnecessary feature creep.
This is how I have translated what I learned in Requirements Engineering to help me be a better team member and software engineer. Hopefully you can garner some gems of knowledge and use them in your work as well.