I would like to point all people in this thread towards the classic paper "A Rational Design Process, How and Why to Fake It" by David Parnas and Paul...
Putcha: Â You ask the $64,000 question: "If people like you (I hope most of RE Group) believe strongly that BA &Â RE must be separated from Design as far as...
Keith, I totally agree about the "Rational Design Process", one of the greatest technical articles ever written in the SW Engineering field. One of the...
Putcha, I think that it is interesting to look back at the history of how Use Cases got to be considered to be OO when they clearly are not. Grady Booch, one...
... This is one of many examples of people who think they are doing requirements but are in fact documenting architectural decisions. Bank cards and PINs are...
Hi Sometimes it is difficult to determine what is "requirement" and what is "design" (or "an architectural decision"). Here is one perspective on why this: 1....
Roger, I am not sure that I totally follow your reasoning with regard to authentication. Identification is about who you claim to be and authentication is...
Dear Don, Roger, Members / co-professionals and friends:  The point made by Roger (in the post and his blog) and the explanation given by Don are very...
Thanks DON:  We learn that "WHOLE > SUM OF PARTS". With Three Amegos and RUP UML upto 2.0 , it seems "WHOLE < ANY PART". Yet we can MAKE MOST OF UML with...
Donald, Absolutely right! Now, you are at an academic institution - what are you going to do about it? ;-) There are a few places offering Requirements ...
A Rational Design Process. I have browsed through it before and I have done it again. The process is too long. Is there a usable summary that can be taught...
Don/Keith, I met a UVA CS professor who said requirements problem is the hardest and there a weathy literature to draw upon. His name is John Knight. Search...
Don, I agree - I've used a very similar approach successfully with several teams, both waterfall and agile. Some minor variations: Step 2 - I have found it...
Putcha, There is no single standard repository of reusable requirements, and I doubt that there ever will or even can be. Most reusable requirements must be...
Keith, You point out an interesting point. Here I am, with a fairly low impression of academia in general in terms of the practicality of what is often taught,...
Putcha, You may have a misunderstanding as to what we meant. At least it sounds so from your comments. The paper "A Rational Design Process, How and Why to...
Jerry, When I used to lead requirements teams, I would typically include full-time 3-6 members as well as include domain experts and stakeholders on an as...
Huet, Good points. Like any process description, it is a simplification and variations are often useful. There is also a lot of overlap due to iterative,...
Don, Do you require requirements engineers any domain knowledge in your team? Since you have domain experts that have all the domain knowledge needed, do you...
Jerry, Requirements engineers are far more effective if they have some domain experience. But they will pick it up if they work close enough with the...
Hi I also have worked in many domains over my career. Having domain knowledge is useful, but the crucial thing is being able to *learn fast*. The business...
Ashley, Very true. It is also a fun part of being an RE. Constant learning and lack of boring repetition. In fact, I start a new project today in a new...
I am not convinced by Don and Ashley. This is from the perspective of Don and Ashley, that is to get a job and learn. But from employers' perspective they ...
I find this thread a bit confusing ... First, Parnas & al were dealing with software engineering, which is not the same as system engineering. The former has...
I will try to go against the wind ... Whereas Parnas & al article is indeed pivotal, it deals with software engineering, not with system engineering. As I see...
That points to a basic flaw with the way UML describes actors as the source of interaction, namely the confusion between agents and roles. It's logically not...
Many of the lessons learned over the last 20 years in software engineering apply equally to systems engineering, either as is or with some modifications. In...
