Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: vodzurk on May 23, 2016, 07:30:43 pm
-
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!
-
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.
-
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
-
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.
-
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 (http://maclark.co.uk/wp/?attachment_id=16#main)).
Mmm... lots to think about!
-
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.
-
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.
-
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?
-
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.
-
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 :)
-
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.
-
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.
-
Before starting with requirements engineering & management I recommend to do some requirements engineering & management of your requirements engineering & management ;)
-
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!
:P
Edit: Also, I have done :P. 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.
-
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.
-
If want to drop an email to Sparx support we can send you an updated whitepaper on Requirements Management.
Otherwise see:
http://www.sparxsystems.com/downloads/whitepapers/Requirements_Management_in_Enterprise_Architect.pdf
-
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.
Hi, good advice without a doubt, but as you say, expensive. Also embarrassing, as after 4 years of formal training for this position (mostly classroom), and finally competing for the job and getting it Q4-2015 (within same company I was developer/analyst at)... to say that I need to hire someone to do my own job might shorten my career here :).
All said, I think my employers have been very happy with my work so far. EA investigations are a background task I'm chipping away at. No projects have used it thus far (other than for a few diagrams). My projects seem to range from (1) small piddly things involving a few stakeholders and turnaround of less than a couple of months, to (2) pretty small time-wise and stakeholder-wise but reasonably large impact on our business, to (3) global strategic projects involving project teams and 1000's of end-users. It's those from (1) that I'm trying to extend into more robust methods, as impact and timescales are small. For (2) and (3), I fall back to our company standard that I'm confident with and meets all my employer expectations (in my view, it is pretty well developed, though paper-based... however it can be picked up by non-Requirements Specialists which is a bonus in many ways). When I'm 100% up to speed, I aiming to take more advantage of EA across (2) and (3).
-
If want to drop an email to Sparx support we can send you an updated whitepaper on Requirements Management.
Otherwise see:
http://www.sparxsystems.com/downloads/whitepapers/Requirements_Management_in_Enterprise_Architect.pdf
Hi Dermot, greatly appreciated... is the updated whitepaper the same as in: Registered > Resources > White Papers > Requirements Management in Enterprise Architect ?
I've submitted a support request as advised. I'm borderline information-overload at the moment. I've at least 2000 pages of information I need to read (stacked up next to me... Volere, various RE books, 30+ research papers) over the next few weeks (doing an MSc in my "spare" time with dissertation in Requirements Engineering phase, which is going great alongside planning my wedding, argh! I expect I'll have no hair by September).
The PDF you linked above, I think was the first thing I printed (and read, honest!) after purchasing EA... I think maybe after my first attempt to read it a few months ago, followed by lots of dabbling, maybe its time to re-read.
-
I know what you're talking of. Luckily, I have left this behind me and can say "I survived it". Good luck with all your projects. And, as one of my former companions said: an elephant can not be swallowed at once. Only in small slices...
q.
-
I know what you're talking of. Luckily, I have left this behind me and can say "I survived it". Good luck with all your projects. And, as one of my former companions said: an elephant can not be swallowed at once. Only in small slices...
q.
Exactly this :). I'll blunder about a bit with small stuff that nobody will lose any sleep over... and hopefully in a year or so I'll be fully up to speed with it.
Seems crazy that there's so much taught material on so many elements of RE... yet so very little of actual tool usage comes into the classroom. I see a gap in the market! ;).
-
Just look at DOORS' UI. They stopped developing that mid 90s (I guess) and it's still (one of) the market leader(s). Requirements are still underestimated by people who should know better. Lots of projects fail or stumble seriously because of the wrong requirements handling. (Should I mention the Berlin airport here?)
q.
-
Just look at DOORS' UI. They stopped developing that mid 90s (I guess) and it's still (one of) the market leader(s). Requirements are still underestimated by people who should know better. Lots of projects fail or stumble seriously because of the wrong requirements handling. (Should I mention the Berlin airport here?)
q.
Ooof... I didn't realise that about DOORS... I've only seen a few screenshots of it, but since seeing the price it weighs in at, have stayed clear. TBH, I think it's probably more industry-targeted to large engineering work packages and their design changes (basically; set up a process to feed it and then feed it for years, the old "if it works, don't fix it" story)... so will probably end up staying clear of it. I can't believe it's barely updated. You'd think they'd at least feed the requirements into it and get them moving forward... unless DOORS killed DOORS?
I don't know the story behind Berlin Airport... a quick glance at Wikipedia though has it looking more like a PM failure (timescales; though likely Reqs related) and corruption. Know any *short* reports on linking the failings to requirements? As for global corruption, lets start an EA project to fix that ;D.
-
The short story behind the airport is this.
Politicians: Build an airport with all bling-bling.
Companies: Here it is with your requirements. Takes €1.7 Billion.
P.: Go on. Start building.
C.: Start to build.
P. (after a while): Oh. This is much too expensive. Cancel Req. A, B, C...
C.: Cutting down.
This happens several times. In the end a lot of needed requirements were cut also and they needed to be re-introduced. Things don't fit everywhere. Current (planned) costs: 5.3 Billion - and rising.
There are for sure many reasons why this has failed. But the starting point was juggling with requirements the wrong way. More here: https://en.wikipedia.org/wiki/Berlin_Brandenburg_Airport (https://en.wikipedia.org/wiki/Berlin_Brandenburg_Airport)
q.
-
Hi
Have been following the thread and I know what you are going through, I specially like to manually number my requirements.
Have used RaQuest and DOORS and both are good tools, but you don't need them to start with; EA manages requirements very good.
Is good to hire a consultant like Qwerty just posted, but if you don't want to spend a lot just buy my book and it shows you how to do all you are asking here.
UML - ERP Workshop, writing a Business Requirement Document for the Inventory Control.
This can be applied to any system I just used my own system which has a one module of of 9 named "Inventory Control"
Happy reading.
.
You can find it here:
https://leanpub.com/uml-erpworkshop