Requirement Engineering theory: In most of the requirement engineering publications, the focus is on management aspects. The collection and management of requirements is discussed extensively. In the following blog I discuss important aspects which are not sufficiently considered in the RE theory. I start with the definition of Requirement Engineering in the book “Requirements Engineering Fundamentals” (Klaus Pohl, Chris Rupp). Read more
Tag Archive for: Functional Requirements
In the first part of the blog I defined the term Implicit Testing and discussed root causes for the need of implicit tests. Now, in the second part I will focus on the disadvantages of such tests and on possible solution approaches with the goal to avoid these disadvantages. Read more
In larger safety-critical projects, quite often I hear the following statement: “Well, the Requirement A is indirectly or implicitly proven with the test XY!” Do you know this sentence as well? Have you ever experienced what can happen in late project phases when you have tested many requirements indirectly?
The blog defines the term in part 1 and it discusses the causes of implicit testing. Read more
The book “User Stories” from Mike Cohn (ISBN 978-0321205681) has inspired me to think about the relationship between user stories and requirements. In software development, agile methods are often preferred in recent years. The classic approaches, especially the waterfall model and the V-model, seem to be more and more outdated.
As a result, user stories are preferred more and more. Do user stories really help to deliver better software quality? Read more
If you are newly engaged in the area of functional safety, then you will encounter fairly quickly the terms “structural source code coverage” and “requirements”. The specification of technical systems by requirements is, of course, also common in non-safety-critical areas. By contrast, the subject structural source code coverage is almost unknown outside safety-critical projects.
In this blog I want to discuss these two methods and the underlying processes. In particular, the question of inter-dependence is exciting. Read more
According to my observation requirements engineering in general doesn’t get the appropriate attention. If you consider software and/or hardware projects which failed, you can see that often a missing or incorrect requirements engineering is one of the major causes. If we go further and consider the types of possible requirements, then you can make a classification into functional and non-functional requirements as a first step. In general, the number of functional requirements, will be significantly higher than the number of non-functional requirements.
Usually, functional requirements are much more homogeneous than non-functional requirements. As the name implies, the functional requirements describe the function of the system to be developed. The validation of the correct implementation can usually determine consistently over a test. After a first version of architecture for the system is developed, a quite good decomposition for functional requirements can be performed. Read more
