Many analysts get to work on end-to-end SDLC (software development life cycle) projects. These projects can be any (or mix) of: waterfall, agile, or hybrid.
If you are the lucky few who get to work on software development projects then you will know the importance of detailed and complete requirements.
Many people confuse functional requirements with system design - and that includes business analysts. It is outmost important that as a business analyst (or a functional analyst) you have a clear distinction in mind between 'what is a functional requirement' and 'what is a system design'.
The following infographic will assist in understanding the distinction between the two.
In various organisations, you will come across the term 'business' vs 'functional' analyst.
Note: in some cases these terms are used interchangeably - depending on skillset of a person. However, there is still a difference as follows:
A business analyst will work on business and stakeholder requirements. These requirements focus on identifying 'why does the business want it' and 'what are the needs of a stakeholder' respectively.
Whereas a functional analyst, will take these stakeholder requirements and define them in much more detail - at a system behaviour and inputs and outputs level.
Generally speaking, an experienced business / functional analyst will know the difference between the two. You may find the comparison table explained on our separate blog between business and functional analyst helpful.
'Experienced' in this context is someone who has worked on many software development projects from scratch. Therefore, this person will be aware details these requirements must contain, and how best to structure them so they are readable by the target audience.
What are the challenges faced by an analyst when writing functional requirements?
Biggest mistakes seen working with varying level of analysts is they confuse stakeholder requirements as functional requirements. In many cases, it is the analyst who confuses the remaining team - and therefore, unable to coach team members on what good requirements looks like. Read our blog that defines the difference between stakeholder vs functional requirements.
Not understanding that requirements must be the 'single' source of truth for the project.
Lack of understanding as to how to write good functional requirements
Lack of training or willingness to learn
Inexperienced analysts making an attempt to write functional requirements without proper guidance
Not keen to understand, write, and maintain the details (e.g. not enough collaboration with other team members to be able to get to the details, and represent accurately in functional requirements). Note: Biggest failure made by an analyst is when they do not collaborate. As per BABOK v3: Collaboration is an ongoing process.
Pressures from other team members who do not understand how detailed functional requirements must be e.g. you may hear 'developers are not robots'
Budgeting constraints from the project
What characteristics must be considered when writing functional requirements?
Atomic
Complete
Consistent
Concise
Feasible
Unambiguous
Testable
Prioritised
Understandable
If you are wondering if considering all above characteristics are practical on per requirement then - let me answer this in short 'It is practical'. However, ability to understand and incorporate these characteristics comes from experience, and the determination to write good set of requirements.
An example of a functional requirement statement can be:
Context: assume there is a need to export a list of comments added by other users on a particular screen.
Functional requirement statement (example):
The system shall allow the <<user type>> to export all comments on <<screen>> in a <<format>> document.
OR to clarify the above statement further:
The system shall allow the admin user to export all comments on comments screen in a CSV formatted document.
The functional requirement statement will then follow-on with its acceptance criteria e.g.
What would this CSV be named once downloaded?
What would this CSV file contain (think columns and calculations)?
Which comments will be included in this exported file (e.g. 'all' selected comments OR 'all' comments)?
When would this CSV NOT be downloaded? (e.g. when no comments exists?) and what would the message displayed on the screen be?
User story format example:
You may choose to define this in a user story format e.g.
As a <<what (think: user)>>, I must be able to <<something / achieve some benefit>>, so that <<purpose>>.
OR to clarity the above statement further:
As a manager, I must be able to download daily user activity report in csv format, so that I can assess activities conducted in the system.
System design:
In most cases, system design is done by the developers, or technical analysts who understands the database and table structure of an organisation well.
Hope the article provided you with clarity. Please feel free to leave your comments, and we will respond back to you as soon as possible.
Meanwhile - book your next business analysis course with us today.
Comments