Distinguish between User and System Requirements

[vodzurk]

Hi Guys,

First post, please don't roast!

How would you guys distinguish between User and System requirements within EA?  Is there a standard best-practice for this?

I can see a Type for each requirement which could be Functional... which I could add System to... would that be the recommended method?

Or do I just group them differently in the Project Browser?  Maybe add them to their own Package?

Edit #1: In paper-based documents prior to EA, I'd typically number requirements as USR-001 and SYS-001... Maybe this would be the way forward?

It sucks being the only BA here, and being reasonably new to it!

Cheers!

[PeterHeintz]

I don’t think there is a standard best-practice here.

However I can give you some information what we are doing, influenced by SPES2020 http://spes2020.informatik.tu-muenchen.de/)
User requirements we call goals and we use the KAOS goal framework for that. To be able to use that we created a own profile to support that notation.

Any other requirement we call solution oriented requirements and those are typically modeled with activities (behavior), state machines (states), SysML Bocks/UML Classes (interfaces). For those currently also textual requirements (SysML Requirments) as some kind of hook or other type of requirements exist. Those textual requirements we differentiate in functional (hook for behavior, states and interfaces), quality (some kind of synonym for non-functional), and constraints.
Your idea regarding different number schema will not work (at least not out of the box) if you want to use auto numbering, because there is only one auto number for a meta type (Requirement). Of cause you can handle that manually or by some kind of scripts.
If we would not use a own language for user requirements, I would put them in a separate package.

[Uffe]

Hello, and welcome to the forum.


I agree there's no standard best practice, so it boils down to how you intend to use the requirement elements in relation to everything else in your models.

The type field you're looking at can be used for this purpose, but it's more often used to distinguish between types of requirement content -- functional, performance, security, etc -- rather than the requirement originator.

You can use package structures, as long as you have a pretty clear idea from the start what categories you intend to use so you don't end up changing your structures around halfway through since that confuses people.

You could model it by creating a "User" actor, an "Architecture" etc, and draw connectors from those to their respective requirements.

For myself I prefer a naming scheme like the one you outline. EA's auto-numbering won't help you much but it never does; set your own req identities and be done.

HTH,


/Uffe

[qwerty]

For fairly large projects it's best to have an own profile with specific requirements elements. What I did is to separate from a stereotype by functional and non-functional Rs. The latter have a tagged value that allows for grouping them in categories. It would also work to use EA's Rs and put them in packages (non-/functional and named accordingly like Legal, Performance, etc.)

q.

[vodzurk]

I don’t think there is a standard best-practice here.

However I can give you some information what we are doing, influenced by SPES2020 http://spes2020.informatik.tu-muenchen.de/)
User requirements we call goals and we use the KAOS goal framework for that. To be able to use that we created a own profile to support that notation.

Any other requirement we call solution oriented requirements and those are typically modeled with activities (behavior), state machines (states), SysML Bocks/UML Classes (interfaces). For those currently also textual requirements (SysML Requirments) as some kind of hook or other type of requirements exist. Those textual requirements we differentiate in functional (hook for behavior, states and interfaces), quality (some kind of synonym for non-functional), and constraints.
Your idea regarding different number schema will not work (at least not out of the box) if you want to use auto numbering, because there is only one auto number for a meta type (Requirement). Of cause you can handle that manually or by some kind of scripts.
If we would not use a own language for user requirements, I would put them in a separate package.

Hi Peter,

Thank you for the feedback!

I was suspecting that there isn't a best-practice, as if there was, there'd probably be a series of tutorials on it.

I'm also suspecting its less than ideal to use auto-numbering, as it embeds this info in the title... it's not separate... I was hoping to be able to bang the identifier on the top of each page of a Requirements Catalogue.  Add in what you say about it being a single number... that kinda sucks for SYS-001 and REQ-001 being tough (nevermind going into sub-requirements being REQ-001.1.4 and linked to their SYS-001.1.4 implementation details).  Plus with auto-numbering, there'd be times when I wouldn't want it to update as it could break earlier print-out references/email-discussions.

SPES2020 looks a bit of overkill for my needs (solo BA)... so I'm trying to keep things simple and evolve.  It's frustrating not having peers.

I think I'll take your hint regarding separate packages though, one for User, one for System.  Though that now gives me an issue that I've partitioned the work into sorta-logical "screens"... which was so I could add in wireframes, use cases, everything associated with that bit of the system under one folder (link).

Mmm... lots to think about!

[PeterHeintz]

Just for info:
Instead of embedding the auto numbering in the title, you can assign it to the alias of the element. So as long as you do not edit the alias you have no risk to delete the number by mistake.

If you e.g. intent to bind use cases to user requirements I would hold the use cases separate and connect them e.g. with refinement or dependency or trace relation with a configured relationship matrix (Tool/Relationship Matrix). At least that works fine for me.

[qwerty]

You will likely not have EA control the uniqueness of your requirements (which is mandatory). Either look for RAQUEST (which is an EA add-in) or use some monster like DOORS.

q.

[vodzurk]

Hello, and welcome to the forum.


I agree there's no standard best practice, so it boils down to how you intend to use the requirement elements in relation to everything else in your models.

The type field you're looking at can be used for this purpose, but it's more often used to distinguish between types of requirement content -- functional, performance, security, etc -- rather than the requirement originator.

You can use package structures, as long as you have a pretty clear idea from the start what categories you intend to use so you don't end up changing your structures around halfway through since that confuses people.

You could model it by creating a "User" actor, an "Architecture" etc, and draw connectors from those to their respective requirements.

For myself I prefer a naming scheme like the one you outline. EA's auto-numbering won't help you much but it never does; set your own req identities and be done.

HTH,


/Uffe

Hi Uffe,

Thanks for the info...

I'll do as you advise and stick to the type field being used as you describe, either functional or categories of non-functional.

I'm noticing what you mention regarding package structures (terminologies slowly coming to me)... One requirement related to a specific screen in the app... and as the requirements gradually come out, it turns out that this impacts a few other screens... arrrgh!  My beautiful package structures ruined!

User and Architecture actors is an interesting one... though it sounds a bit more of a work-around, and potentially confusing any Use Cases... as the actors would be linked to reqs.

You mention 'set your own req identities and be done'... would this be best done as the requirements' title like USR-010.2.4 - Applicant can upload their resume?  Or with USR-010.2.4 as the alias and Applicant can upload their resume as the title?

[vodzurk]

For fairly large projects it's best to have an own profile with specific requirements elements. What I did is to separate from a stereotype by functional and non-functional Rs. The latter have a tagged value that allows for grouping them in categories. It would also work to use EA's Rs and put them in packages (non-/functional and named accordingly like Legal, Performance, etc.)

q.

Hi Qwerty,

Thanks for the feedback.  I hope within a year I'll be fully conversant in EA, and understand more about things like profiles.  Unfortunately at the moment, I'm a bit of a newbie... so trying to stick with the utter basics first.  I think to start with (until I'm totally au fait with it) I'll be sticking with EA's requirement packages as you describe.

[vodzurk]

Just for info:
Instead of embedding the auto numbering in the title, you can assign it to the alias of the element. So as long as you do not edit the alias you have no risk to delete the number by mistake.

If you e.g. intent to bind use cases to user requirements I would hold the use cases separate and connect them e.g. with refinement or dependency or trace relation with a configured relationship matrix (Tool/Relationship Matrix). At least that works fine for me.

Ah, ok, I think this (identifier in alias) answers one of my earlier questions.  I assume then that if I were to use/build a documentation template that I could display that field in each Requirement Catalogue entry?

Dependency matrices are on my list of stuff to get the hang of too... I might have a quick "play" this afternoon with it and see if I can do this "configured relationship matrix" thing that you speak of 

[vodzurk]

You will likely not have EA control the uniqueness of your requirements (which is mandatory). Either look for RAQUEST (which is an EA add-in) or use some monster like DOORS.

q.

Hi again Qwerty,

The thought of using something like DOORS or even another product or add-in at this stage terrifies me... this whole EA thing is quite a hurdle from zero experience with it (I've probably done every course on the planet regarding requirements, but none cover tools other than naming them, grrr!).  We actually have two unused floating DOORS licences at the site I'm at... but there's no way I'm adding that to my to-do list just yet!  I quite like that my tools only amount to a PC, office, and EA.  As a developer up until a year ago, my tools were cringe-worthily expensive!  No more cringing thanks to Sparx

Looking at RaQuest... being so green to EA, I'm probably not going to understand the benefits for another year.

I think for now, I'll trust in the posts above and hit up the Alias with the requirement identifier... likely manually generated, so I know what's going on between SYS-010.2 and USR-010.2, etc.

[PeterHeintz]

I assume then that if I were to use/build a documentation template that I could display that field in each Requirement Catalogue entry?

Yes with a document template you can do that.

Looking at RaQuest... being so green to EA, I'm probably not going to understand the benefits for another year.

With RaQuest you can handle the requirements more in a table rather than as elements in the properties dialog or on a diagram + some other features.
I used Raquest many years but now not any more. This is mainly because of the Specification Manager is there for a while, satisfies my need and the other features I do not need, further on Raquest does not fit well to own defined requirement profiles.
As long as you do not have requirements engineers not able to specify requirements in EA or defined by some strong organizational policies to use something else (not working in huge endeavor) I assume that doing requirements engineering in EA is good.

[StefanPears]

Before starting with requirements engineering & management I recommend to do some requirements engineering & management of your requirements engineering & management

[vodzurk]

Before starting with requirements engineering & management I recommend to do some requirements engineering & management of your requirements engineering & management

Dammit, I read that 3 times before I saw the smiley!



Edit: Also, I have done .  Came up with paper-based catalogue with traceability 6-9 months ago with a suitable project (utter nightmare, with only 12 user requirements, which then translated to about 30 system requirements, each of which was versioned prior to agreement and putting out to tender)... and that was refined from textbooks/lessons/webinars and our previous BA's way of documenting requirements.  Now I'm trying to reach the same level of detail + documentation with EA.

[qwerty]

Since you will anyway get flooded with new information, here's a not so cheap advice in short time: hire a requirements specialist. There are quite a lot out there . and unfortunately also not too few who 'think' they are specialist but only good salespersons on their own behalf. If you happen to find a good consultant you will save a lot of money in the long term. If you're unlucky ... well, I guess you know.

q.