Friday, March 8, 2013

Requirements Engineering


as there have been some misunderstandings regarding my geo-sensor simulations, I worked this week on requirements engineering.

I made a requirements engineering specification, like I learned it in a course at the University of Applied Sciences Salzburg a view semesters ago (by Roland Graf and Dietmar Glachs).

I also found the the Berkley lecture 6 about scenarios quite useful for that purpose:

Here you can find my requirements engineering document:
Requirements Engineering Document

I uploaded a PDF-document, because I find it quite hard to format a table with blogger ...
I am thankful for ever comment or suggestion :-)

My next steps: I want to look at standards, before I continue. I already read some papers from Bernd Resch (a scientist working in Heidelberg/Germany), where he writes about geo sensor standards. I should also check out that website:



  1. thx for the document. I will check it out the next days. The idea about digging into standards is very much appreciated as well. BTW, Bernd is now working in Heidelberg/Germany ;)

  2. Thx for the hint, I updated the info about Bernd :-)

  3. I reviewed your requirements document. For a basic starting document it is ok. However, more effort has to be put in the description part of the use cases. Normally, the actions within the use case are described in coherent flow-text to provide more details to the stakeholders. Furthermore, you should think about sequence diagrams as well. These will help you a lot to detect possible flaws or missing points within your versioning processes.

  4. Hi Thomas! Thank you for your hints! I just updated my document. I changed the description part and added sequence diagrams. You are right, they are quite good for detecting missing points!
    So am I now ready to start with the real software? :-)

  5. Hi Tanja, well done getting up a requirements document. My main concern is that the requirements

    * [RQ-1] MUST

    Sensors generate data that is stored via a version control system

    * [RQ-2] MUST

    A scientist combines different sensors to a new meta construct

    * [RQ-3] MUST

    Another scientist combines meta constructs to meta-meta constructs

    * [RQ-4] MUST

    A scientist can view the data via a graphical representation

    * [RQ-5] MUST

    Two scientists perform different analysis methods and fuse their work

    * [RQ-6] CAN

    If graphical representations are stored as well in the version control system, a piece of
    software, like a “time machine” can be created for quick access

    don't tell me anything about *why* these are requirements. I'm still looking to see stories about why scientists (or anybody else) actually want these things, so for example:

    "John is a meteorologist. He has many sensors in a field study each generating temperature readings. In order to conduct his research he must securely store all the data reliably as it comes in from the sensors."

    This single user story would generate a requirement for secure and reliable storage. Making the requirement "Sensors generate data that is stored via a version control system" without any associated user story is back to front from my point of view. So too all the other requirements. I really want to see a top level story for each of these requirements that explains why any of these things are desirable in the system.

    I'm also concerned that terms like "meta-construct", "graphical representation" and "analysis methods" are far too vague and ill-defined to be included just like that in a set of requirements. Again, I'd like to see high level user stories specifying in detail what scientists would want from this system and how they would use it. If you are not sure what graphical representations or meta-constructs a scientist would use, then I believe it's critical to find specific examples of such things and include them.

    In the ideal world you'd be talking to real scientists and discussing their needs, but I understand that this is likely outside the scope of your current project. Of course, it's not uncommon to receive a requirements document without being able to talk to the end users, but I think every engineer should try their best to discover the real stories that underly the requirements, to provide feedback, and ensure that requirements do actually match that someone in the real world would actually want to use.

    Hope that doesn't come across as too critical. You're clearly putting in a lot of effort and doing some great detailed work, but I worry that a lot of that effort might be mis-directed if we can't pin down in more detail how scientists might realistically use the system you are creating.

  6. Hi Sam,

    Thanks for your comment and sorry for the delay in response.
    Last week there was spring break in Hawaii and I went to Big Island. I was also working on my two German business papers.

    I updated the requirements document and added a user story for each requirement (page 1).
    Is it fine like that?

    I really appreciate your comments! It is good to see another point of view. I think the user stories make the requirements more clear.

    However, I think my goal is to write a scientific paper about geo sensor networks referring to literature (like papers and books, not blogs) and making a practical implementation as a prototype. I think my implementation should be a prototype for proving that my theoretical work is ok. It's not software someone is using. People should read the scientific work and get ideas, how to make a concrete implementation for themselves out of my overview.

    Our university at home said they prefer to get a master thesis without a connection to a company. It should be more theoretical than a bachelor thesis. When I wrote my bachelor thesis, I worked together with my company. I made a concrete implementation the company is using now. But as far as I understood, that is not the goal of a master thesis.
    From my colleagues at home I know that nearly nobody is working with a company and making concrete implementations.

    I hope I am not wrong with that ... otherwise Thomas may want to add something?


  7. Hi Tanja, thanks for the update. The user stories you added to the requirements document are a great improvement. My own inclination would to keep asking for more examples and details, e.g. graphics that scientists might want to look at etc. but as you say if the your university is happy for you to create something that won't ever be used by anyone, then not focusing on the users is fine.

    And certainly if you have already done some collaborative work with a company, that sounds find for this work to be more theoretical. With the user stories now you have at least solidly grounded the system in terms of what people might do with it.

    I guess the issue for me is still in terms of all the decisions you have to make regarding the implementation details. For me I would always be trying to refer back to what the end users of the system would actually want, but as long as Thomas is happy I think we can probably move on. :-)