Crash course in requirements engineering

facebooktwittergoogle_pluslinkedin

This article is part of the bigger series about my Software Engineering internship this summer. To read all the posts, simply visit the category archive.

The first week of my internship is almost over. I started slowly with setting up a basic infrastructure for my project. Getting tools from the company’s tool chain (I’ll return to that later) and most importantly:


Okay, I just had to try out the embedded twitter feature of WordPress 3.4, but it was still worth sharing. And I’m quite convinced that this isn’t just nonsense. It just is more fun to work at a project for which you have a cool name.

And before I move on I’ll just briefly explain again what my internship is all about: During the next 14 weeks I’ll specify and develop a system to create, manage and display skill profiles of all our employees, so that they can be used in offers in a consistent way. The exact solution and the way to get there is largely my decision. I do have some budget for licences and depending on the estimations even potential team members that help me to develop this application.

Where to start?

But after I’ve somewhat settled and was ready to get some real work done, I realized that I didn’t really know where to start. I got a short briefing two weeks before when I “signed the contract” for the project and this looked somewhat like this:

The whiteboard after the intro meeting for my internship

The whiteboard after my intro meeting, showing the structure, plan and organization of the project

So, I knew I had to do “analysis”, which I translated to “Requirements Engineering”. But I’ve never done this before. And I can imagine that the start of the very first project might be a bit tricky for most people. In particular if you have a project where you are able to make almost every decision of your own as in my case.

So I took a second look on the picture on the whiteboard. So there are some major things I can start with. Let’s go through it step by step.

Processes

Business people like processes. I’m a business person, I like them to. They give us the feeling that everything is under control. So also in this case. I started looking at the involved processes of the company and analysed the impact these artefacts have. Would changing the system have a large impact on those processes? What would speak against a change from this perspective?

With the processed I automatically also had all the involved roles, users and functions and therefore most of the stakeholders.

Identify Stakeholders

I used to call them users but that would be misleading. Although the users of your system are your stakeholders as well, there might be stakeholders which are never going to use your system.

The three main stakeholders for my project are:

  • The executive board, as it pays the whole stuff.
  • The human resources department, which currently is responsible for all the profiles of our employees. The people there create and update the profiles and are the solely people that have access to all of them.
  • The sales department which uses the profiles for their offers.

So I need all the requirements from this people and I’ll get them by talking to those people. So I scheduled interviews with people from all those groups.

Requirements collection

I’ve been working with the current profiles before, so I knew most of the pain points already and what exactly the purpose of these profiles is. Still I tried to forget this knowledge for an hour and focus on the different partners in these interviews. Everybody had some new points I didn’t knew of.

I didn’t use any particular technique during those interviews. I obviously prepared some questions and took frequent notes. The questions looked like this:

  • What are the biggest problems with the current system?
  • What is good about the current system?
  • If you could change one thing, what would you change about the current system?
  • Are the problems big enough to justify a new system?

The obvious line “I’m designing a new system that gets rid of the current employee profiles. What are your requirements for this system?” didn’t lead to any success (okay, honestly I didn’t even try it). First, I already knew the basic requirements. So the requirement “I have to be able to create profiles for employees” wasn’t what I was looking for.

The first two questions focus on the delta between a potential new system and the current one. The second question helps me prioritize the requirements. Another tricky part, as the question “How important is requirement X” leads to quite inconclusive answers. The last question finally helps me decide how I can argue for the appropriate amount of resources.

I did encountered some problems during my discussions though:

  • Some people tend to digress to talking about problems not related to the project.
  • At this early state of the project I don’t want to lose time for details. When asking what is bothering with the current profile, the font size isn irrelevant.
  • Different technical understanding leads to different requirements. While talking to one person used to be a software architect he quickly draw a uml diagram on the whiteboard to illustrate his point while another person had problems formulating potential features because it seemed to complex.

Boiling requirements down

Getting the requirements in a more useful form was my next step. Describing the weaknesses and strengths of the current system and the proposed solution with a new one took me quite a while. I tried to get rid of all the technology and implementation aspects (expect in the non functional requirements, but we will come to that later). The best way to get there was in the end a simple table with a all the requirements listed and categorized in MUST and CAN requirements.

Functional requirements

I don’t want to bore you with functional requirements. But there were some interesting ones I didn’t think of first and might be quite tricky:

  • Internationalization
    The company is growing more and more international. So it should be possible to create a German, English and Spanish version of the same profile.
  • Access management
    Who is going to be able to view or edit profiles of whom? Is it only the HR which is allowed access to all profiles? But what if Sales needs them? This is more of a question regarding the process, but will of course affect some features of the system. Currently there is no consensus yet within the company.
  • Versioning and publishing
    When changing informations on a specific profile should the previous version be stored? Should the new version even go through some kind of review process form the HR department?

Use case diagrams

Sometimes theory is outright not useful. I wanted to be well- behaved and use something I learned the year before in a software engineering course at University. A UML Use case diagram. I started thinking about actors, use cases and their interactions and drew something up. I couldn’t come up with any diagram that would really provide me any further information without being confusing. So I made some research and found Martin Fowler’s conclusion:

Use cases appear in the UML in the form of use case diagrams, but these diagrams are of little value – the key value of use cases lies in the text which is not standardized in UML. So when you do use cases put your energy into the text.
Martin Fowler

I followed this advice and simply described the use cases via text. I’m still not really sure in which situations a UML use case diagram really adds value.

Non functional requirements

I had some non functional requirements. I looked at the following types:

  • Usability
  • Reliability
  • Performance
  • Maintainability
  • Implementation

Usability, reliability and performance are not a major focus. Usability might be the most crucial of the three. Creating a profile requires filling out a lot of forms and that should be as intuitive and fast as possible. As the application isn’t that critical, reliability and performance is not that much of an issue. Maintainability mostly includes forms of documentation and automated testing.

But implementation was quite an important one. The system should be as extensible as possible. Forward compatibility in this context means:

  • easy change of the corporate design for the profiles as they are used in offers and are sent out to (potential) customers;
  • easy change of the layout and content of the profile if suddenly new information is needed.

Which means I have to think about some kind of templating engine. Exporting to MS Office Word will already be difficult enough, but this seems to be even more tricky.

Secondly I was asked to implement the whole system based on the application stack of the company. Which makes quite sense will be quite troubling for me. A lot of new technologies I’ve never used before…but more to that next week when it comes to technology decisions.

I’ll just leave you with a last question: