Interviews at Business Unit Z
Interview Concerning Requirements Development
Assessor:
The purpose of Requirements Development is to produce and analyze customer, product, and product component
requirements.
Thus three major questions arise :
• How do you collect, evaluate, and refine customer requirements ?
• How do you transform the customer requirements to technical product requirements ?
• How do you specify the requirements, evaluate the cost, and validate later the requirements
together with the customer ?
Ken:
The sales department is contacted by customers. Requirements from customers are collected and registered. The
customer requirements are reviewed by a technical expert in the sales department and forwarded to the
responsible internal department. E.g. If there is a software requirement it will documented by a technical
representative in the sales department and forwarded to the control systems software department.
A bulk of requirements from a certain customer are then reviewed by a team of a representative from the
software department and a representative from the financial control department, to estimate the cost impact and
to analyse the technical feasibility. This leads to a list of reviewed and accepted requirements plus a cost
proposal. These data are then used by the sales department to come up with an offer and agree upon a contract
with the customer.
Assessor:
Ok. This explains how requirements are collected, but how are these requirements refined into a set of technical
requirements to adapt the existing product for the customer needs.
Ken:
Well, I forward all technical requirements to my software developers and they come up with a list of changes
they propose. I look at this list and decide upon the changes to be made.
Assessor:
How does this list of change proposals look like?
• Is it just a list of code changes to be made ?
• Does it describe also how the interfaces between product components might change ?
• Does it describe the interfaces to other technical components or systems of the customer
environment (external interfaces) ?
• Does it also contain a mapping of which modules within the product to adapt ?
• Does it contain a size and refined effort assumption of the change ?
Ken:
Aha, so you expect that we have something like a design and change proposal to the design. We only have code
and a change proposal to the code parts. Also, as we miss a well documented architectural design we can
document the customer requirements concerning interfaces but cannot evaluate how the interfaces between
software functions are impacted, before we start coding.
Assessor:
Hmm, if you have no separation between functions of the software on the level of an architectural design, how
do you allocate requirements to certain components of the product ?
Ken:
Page 1 of 3
Interviews at Business Unit Z
We do it just by the code analysis. Also our software (all three parts: sensor reading, visualisation, control
data/input management) is coded in such a way that each change requires to re-compile the whole product. Thus
we just take the list of code changes required and assign them to the developers.
As side effects happen sometimes all developers are responsible for all modules. But that is driven by the current
software architecture.
Assessor:
How do you define the requirements, once they have been analysed ?
Ken:
We write a so called software requirements document and a user requirements document. The user requirements
document contains the list of customer requirements collected and evaluated by the sales department, and the
software requirements document describes for each customer requirement the list of changes needed in the code,
plus a cost estimation done together with the financial control department.
Assessor:
Ok, please give me a copy of a sample user and software requirements document. Interesting, it carries version
1.0 ? Does this mean the requirements never changed.
And how do you ensure that the requirements are fulfilled ?
Ken:
Well , the requirements changed. We only keep a version 1 attached to the original contract. All further incoming
requirements fall under a change request reporting procedure and require the customer to pay extra. They are
kept in the change management system.
We first test a system ourselves with the use of test data generators (like a simulation environment) which we
developed ourselves, and give the customers beta releases to realise integration errors and solve them.
Assessor:
Once you established the product requirements, are they reviewed again with the customer ?
Ken:
No, they just trust that we will implement correctly their customer requirements within the cost planned.
Assessor:
The next block of questions deals with how efficiently you manage the above discussed practices.
Thus the following major questions arise :
Is there a requirements development policy ?
Do you plan, track, control the status of requirements ?
Do you review them together with top management, customers ?
Ken:
There is no policy or standard for software requirements development. There is the general ISO 9001 handbook
but this is much hardware related and speaks general about design inputs. It does not go into enough detail so
that it would be a guideline for a software project to develop requirements.
I described before how we collect requirements, estimate cost, and agree a budget with a customer. We usually
stay within the budget until a first delivery but we had lots of corrections after delivery due to integration
problems.
Assessor:
Page 2 of 3
Interviews at Business Unit Z
What causes the integration problems?
Ken:
As said before, as we miss a clear separation of code into functional blocks which can be linked by standard
interfaces, a code change can have impact on a number of other modules. And these side effects we do not
recognise early enough.
Assessor:
So you cannot evaluate the risks fully, as you do not know how many of the modules are affected by a certain
software change.
Ken:
Yes.
Assessor:
What about the reviews and some other questions:
•
•
How do you allocate personnel to the modules ?
How do you train the people in requirements development techniques ?
Ken:
Training is offered. But the time pressure is so high that only myself could go for a training.
The allocation of personnel to modules is not possible because of the monolithic code architecture. All can do
the work on all modules, so I just take parts of the code change list and just assign this part to someone of the
developers.
We make a two weekly progress review with the department head and with the quality control group. In these
meetings we show the status of each requirement and discuss deviations in the implementation or the estimated
cost.
The results are monthly represented to the top management.
The customer is only involved at the start and later when the system is delivered. We already discussed that it
might make sense to meet more often with e technical expert from the customer side to realise integration issues
earlier.
Assessor:
We always speak about project leader and developers, is there the role of a designer for producing an
architectural software design.
Ken:
I should do that as well, but as the time is short I did only a rough overview diagram.
Assessor:
Thank you, lets discuss the next process.
Page 3 of 3