[ros-kernel] FURPS

[Jarmo M. <ja...@mu...>]

Hello,

I thought that it would be cool idea to have a web page where
users would have a possibility to see and add requirements. These
could be possible to see/add per module. It should be controlled
someway. There would be many requirements that would be the same.
Also, there would be requirements that is not possible to
implement because other requirements are the opposite. If they all
are reasonabe requirements, this way you could see that some kind
of option is required. One person per module could accept the
requirements.

We are using FURPS (functionality, usability, reliability,
performance, and supportability) at work. It's good way of seeing
and documenting what could be done. We collect all requirements
and write them down. We collect all that we can think of, but we
will accept only must requirements for version 1.0 which we need
as soon as possible. After the version 1.0 is up and running, we
add less important, but still important features to system. I know
that some of my ideas are too expensive to implement, but I added
them to the list as well.

My way of doing it is to first add a general requirement, like
"Company has employees". Then I start splitting this req to
smaller pieces:
- Add new employee
- Update employee
- Delete employee
- Delete is not possible, if employee has hour bookings
- Reject duplicate employee by full name
- List employees
- List employees of department
- Mark employee as deleted
- Mark deleted employee is not listed generally (this is a bit too
abstract req)
- List mark deleted employees
- Employee has following data: xxxxx, yyyyy, zzzzz, etc.
- etc.

Most of my reqs are FRs (functional requirements) and some are UR
(usability reqs). I collect data too and put them as SR
(supportability reqs).

I hope that you got the point. When you read this you might not
like something, or think that it's too complicated, or there is
something missing, or req is not needed, or it can be implemented
later, etc.

When you are very detailed in your reqs, you get a lot of
information
a) for what could/should be done
b) for test cases
c) for user interface design
d) for database design
e) for programming

One detailed req is easy to design, easy to program and easy to
test. I am very proud of my work what I have done in two weeks. I
have received positive feedback from my colleagues and from
customer. I feel that adding detailed requirements before we write
a line of code will pay it back. By the way, the reqs are so
general that there are no UI specific things. Some reqs may be
easy with Centura/SQLWindows and difficult with web browser.

When this is done for ReactOS Explorer, the list would be very
long. So, you see how much code you have to write. It also helps
designing source code files. And putting things to classes. And
organising development.

What next? Then the most complicated reqs are analysed with UML. I
think that we make use case diagrams, statechart diagrams and
activity diagrams. We don't make class diagrams. I design database
with ERwin. I will do this after summer vacation.

Was this interesting or not?

JMu