As we presented you some awesome chat tools (Slack, Hipchat and Hall) in our last blog post, we want to focus on the web development process itself. You probably heard and read a lot about all kind of different processes and how to do it right. We can’t show you the “perfect web development process”, because from our experience there is no right process. But we’d like to acquaint you with the concept of requirements engineering.
The perfect web development process!?
To be honest – the perfect web development process doesn’t exist. At least that’s what we think. However, to begin with, you’ll probably start thinking about its process. What we recommend: Get started and use a process! At the very beginning, it doesn’t matter if you’re setting up a lean process, using scrum or some agile technique. Just do it.
Getting started with requirements engineering
Starting in web development you’ll probably have heard all kind of different methods and frameworks, like Scrum, Kanban, and Agile. All kind of similar, but not the same. And now there’s a new kid in the block – Requirements engineering.
According to Wikipedia, requirements engineering refers to the “process of formulating, documenting and maintaining software requirements”.
In contrast to the definition phase in the waterfall model, requirements engineering takes an important part throughout the entire process and the lifetime of a system as a whole.
To put it crudely: Project managers often focus too early on existing solutions, customers can’t express their vision for new ideas, developers can’t communicate their suggested solutions, decision makers are not involved in the operative doing and the real experts are not involved in the decision-making process either. Requirements engineering tries to solve these situations by identifying all relevant aspects at the beginning of a project.
It’s really important to know what you and all your project stakeholders want to achieve before you even get started. It means you need a clear vision about the end result. For this, planning is crucial and requirements engineering helps you throughout the project of keeping track.
Identify relevant stakeholders
Requirements engineering helps you to analyze and define all relevant requirements right from the beginning of a project. Especially the coordination with the project’s client takes an important part. In order to reveal all requirements the project stakeholders must be identified:
- Who’s the decision-maker?
- Who’s working on the current system/platform/website/etc.?
- Who are the users of the new/planned solution?
- What are the circumstances/situations in which the solution is used?
Discover and learn
Having collected the answers of the listed questions, the evaluation of all requirements can take place. Working on the aim and definition of the project will lead to a clear project scope. Especially those working on client’s projects should primarily focus on the definition of the following aspects:
- What’s the aim of the project? What problem should be solved after the implementation?
- What user roles can be defined?
- What are the non-functional requirements?
- Which system requirements must be considered?
- What are the functional requirements?
- Further, additional information?
Functional vs. non-functional requirements
Being not so familiar in web development, you’ll probably ask: And what’s the difference between functional and non-functional requirements?
Let’s put it simply. Functional requirements define certain behaviors or functions/features of a system. This kind of requirement describes the input, the behavior and the outcome of a function which means that this requirement describes what the system should do.
On the other hand, non-functional requirements describe the quality of a system and how the “system should be” (for example: the system should be available for …). Non-functional requirements define the accessibility, usability, maintenance and availability of a system. The definition of functional requirements normally takes place in the system design, whereas the non-functional requirements are detailed in the system architecture.
Both, functional and nonfunctional should be described with real examples, mockups, and/or screenshots.
Having all requirements defined, the web development team can now evaluate the requirements, identify potential risks and secure the different tasks which need to be done.
Mandatory- vs. Nice-to-have features
Further on, the collected requirements have to be classified. At the very least, we recommend splitting your requirements into mandatory and nice-to-have features. Mandatory features define the minimum set of features which have to be done in the project. Nice-to-have features are normally those features which embody the USP of a system/web application/product, but are also those features which are quite time-consuming and complex. Those nice-to-have features are also likely shifted to the expansion stage of a product.
Iterate, iterate and iterate again.
By evaluating and reflecting the defined requirements, you will receive further inputs, demands, and ideas from your colleagues and clients. All steps – from the identification of the stakeholders to gathering the requirements to validating them – are gone through as long as all requirements are clearly formulated and understood by the entire project team and the client as well.
What’s the benefit of requirements engineering?
After all, you probably wonder why you should use the framework of requirements engineering in your next project?
At the first glance, requirements engineering looks kind of similar to the waterfall model. Starting by collecting all your requirements, followed by a project concept and planning. Further on you develop first wireframes and design draft, followed by the coding and implementation. However, requirements engineering is more than that and suits perfectly for an agile project management. In contrast to the waterfall model, all requirements are gathered, defined and evaluated in the requirements engineering technique at the beginning of each sprint. This offers you a higher flexibility on the one hand and prevents conflicts and last minute changes on the other hand.
Which tools to use for requirements engineering?
There are all kind of different tools and systems for requirements engineering available. Many of them offer a comprehensive and powerful set of features. However, these tools seem to be too complex for many web projects we are working in. From our point of view, Google Docs is a perfect fit for the documentation part of your requirements engineering. And you can share your documents easily among colleagues and clients and work together on requirement updates.
Further web- and browser-based tools like Asana, Basecamp or Trello help you to plan and manage web projects. These tools are easy-to-use and work well with further 3rd party integrations. And most important: your clients will make like them too, because of their nice and comfortable user interface.
Implementing requirements engineering in your web development team isn’t that complicated. Nevertheless, it’s important to choose the right time for setting up this new concept. It requires a detailed planning but offers you new opportunities on improving your web development process by getting rid of unnecessary/inefficient tasks/inputs. Identifying and evaluating requirements at the start of each new sprint will help you to avoid discussions about new ideas at the end of a web project.
And don’t forget that a requirements engineering documentation can help you in your quality assurance and testing activities. A well-structured document with all defined requirements will provide you and your customers a great monitoring tool.
Want to learn more? Books for requirements engineering.
Well, there are tons of blogs, books, and sites out there about requirements engineering. If you’d like to get deeper into the topic of requirements engineering, we’d like to recommend the following books:
- Rational Unified Process: An Introduction, by Philippe Kruchten
- Mastering the Requirements Process: Getting Requirements Right by Suzanne Robertson
- Peopleware: Productive Projects and Teams by Tom DeMarco
- UML Distilled: A Brief Guide to the Standard Object Modeling Language by Martin Fowler
This article was brought to you by Usersnap – the top-rated customer feedback platform.