What arethe main differences in methodology between "Requirements Engineering" and "Usability Engineering"? Where do they overlap, where not? Which activities are common between the two and which are exclusive?
3 Answers
We have developed over the last few years our own SWE BOK in our company, and there we see the two disciplines like that:
- Requirements engineering is the first of the disciplines which looks at the problem of the customer (only). It has to ignore completely the solution (even if you think you know it).
- Usability engineering has to think about how to make the solution usable, therefore it defines requirements that ensure that usability will be part of the solution.
- They overlap only in the part where the requirements that ensure usability are defined.
Requirements are seen in our nomenclature like that:
- Functional requirements
- Non functional requirements
- Security
- Usability
- Maintainability
- .... (all the ilities you may find in the context of computers
- Project conditions (requirements which will not change, they are more like constraints).
As you can see, usability is part of the non functional requirements.
-
So requirements engineering is about the problem and usability engineering is about the solution. I like it. +1 Jul 29, 2011 at 14:19
-
4@ Roger. Just a word of caution - dividing it like that in some settings will a. get you nowhere, and b. be seen as a semantic distraction. If it works in a setting, that's awesome and very desirable, but it wont fly in many settings.– gef05Jul 29, 2011 at 15:02
what do you think are the main differences in methodology between "Requirements Engineering" and "Usability Engineering"
Personally, I would not separate these out. I spend a lot of time acting as a business analyst for projects, and whenever possible I make sure that usability is part of the main requirements gathering effort. They may be listed in a sub-category, such as "Interface requirements" or "UI requirements" but the end result is the same - a list of expressions of need that are actionable and verifiable.
What are common Activities and what are exclusive ones...
Again, I see a large part of the efforts as being so intertwined that I don't see value in separating them out. All the usual activities apply:
- requirement statement
- functional details
- test cases
- verification with developers and QA
Edit: I see that mliebelt has posted a different approach; and that's perhaps the most important thing to state here - do what works in the local situation as no two development shops are the same, and so no two approaches will be the same.
I read the two replies by mliebelt and Gray a couple of times. I partially agree with both. It sounds correct to me to define UE as solution-oriented and RE as problem-oriented, but the current studies aim to focus on their intersection.
If we take a look at the recent reference in RE (e.g Alan M. Davi's book: JERM), we see that taking product/solution into account from early stages (i.e. RE) is recommended for developing the right product.
On the other hand, recently, there have been efforts to mix these two concepts, in order to develop products with higher usability. For instance, take a look at "Human-centered software Engineering" by A. Seffah et al. in which the main focus is to bridge the gap between UE and SE.
So I would say, however, previously RE and UE have been treated separately, nowadays, the importance of including usability requirements (and consequently some usability-related activities, i.e UE) in RE activities is being acknowledged. In particular, activities in UE that lead to creation of Usability specification. I still think usability evaluation is not part of RE by nature.
-
Also, I should add that basically RE has its roots in the SE (software engineering) filed while UE is mostly known and used by interaction designers (well, I'm not quite sure which field initiated that, but it has been an effort to deal with the fuzzy concept of usability in a more engineering way) Mar 29, 2012 at 20:43