Requirements Engineering Part 2

---

---

Requirement Types and Sources

There are 2 types of requirements: functional and non-functional. Non-functional requirements describe the quality characteristics of the product. They cover constraints and standards that the system must comply with (e.g. security, performance, usability,…). Functional requirements on the other hand describe functionality that shall be implemented into the product to enable the user to accomplish their tasks (e.g. authentication, administration, reporting).

Knowing these types helps you to identify additional requirements by using them as a checklist. You can go through the list to find additional ones that you didn’t think of yet. Ask questions like “Are there regulatory constraints that our application has to cover?” or “Is it necessary that users can access historical data?”. It´s not uncommon that functional requirements emerge from non-functional ones, e.g. when a legal regulation enforces a certain functionality. You can use the list above as a starting point and extend it over time.

Sources of Change

Once you started to collect requirements it might happen that they change, sometimes even before you released the first version of your application or maybe after a while – don’t panic, that is totally normal. Reasons for changes can be versatile and they can emerge from in- and outside the project. For example:

• the marketplace changes – you observe or anticipate changes and you want to adjust your product accordingly.
• politics of your organization changes – to meet those new politics you need to incorporate them into your product.
• the understanding of requirements change – for some reason the interpretation of requirements change and hence it needs to be implemented in a different way.
• legislation changes – a law that affects your product will be changed or will become effective, hence you need to adapt those changes to keep your product in conformance with the legislation.

You can see that some of those sources are outside your area of influence. It is necessary to observe your marketplace, competitors and legislation to stay up to date. To stay informed about changes that arise from inside your area of influence you need to stay updated about organizational requirements and possible changes caused by a changed understanding. The important thing is that as soon as changes come up it is necessary to incorporate them into the product. For that, there are 2 different approaches:

• Treating the changed requirement as a new requirement (common in agile projects).
• Document the change according to the defined change management process (common in traditional projects).

Depending on your project you can choose the method that suites you best. Both approaches can also be applied for the Requirements Traceability Matrix (which we introduced in the first part) that helps you to keep track of requirements and associated documentation and test cases. However, in the Matrix you should always edit the old entry, so that you don’t loose the link to the other documents. In agile projects you simply edit the requirement and create a new backlog item to initiate the implementation.

Conclusion

Having a list of sources of requirements and knowing possible sources for changes helps you to pro-actively investigate certain fields to find requirements; simply go through the list and think about possible requirements that might arise from each item. Once you created a list with requirements it is inevitable to keep track of changes, otherwise your documentation will quickly be outdated, therefore you need to stay up to date about your marketplace, legislation and your internal politics and in understanding.

With kind regards, your SCM-Manager Universe Team

Links:

• https://www.sei.cmu.edu/productlines/frame_report/req_eng.htm
• http://re-magazine.ireb.org
• https://www.mindtools.com/pages/article/newPPM_77.htm

---

---