RUP (Rational Unified Process) [closed]

I have chosen to use the development method RUP (Rational Unified Process) in my project. This is a method I've never used before. I've also included some elements from Scrum in the development process. The question is what the requirement specifications should contain in a RUP-model? Is it functional and non-functional requirements? And what should be included in a technical analysis and security requirements for RUP? Can’t find any information. Notes about this would be helpful. Hope people with RUP experience can share some useful experiences

回答1:

RUP has 3 main parts:

Roles
Activities
Work Products

Each ROLE do an ACTIVITY and as a result a produce a WORK PRODUCTS...

For example Analyst [Role] Develop Vision [Activity] as a result we will have Vision [Work Product]...

Besides this RUP gives us some GUIDELINES and CHECKLIST to do right our ACTIVITY and WORK PRODUCTS...

RUP gives us templates for WORK PRODUCTS but they are just to give an idea what they may be look like...

Suppose for vision you can use RUP template but you can just use a post-it notes and just write an "elavator statement" like this:

For [target customer] Who [statement of the need or opportunity] The (product name) is a [product category] That [statement of key benefit; that is, the compelling reason to buy] Unlike [primary competitive alternative] Our product [statement of primary differentiation]

Even Work products can be simple statements that you write on your WIKI...They can be in any form...

They must not be "static written" docs... They can even be "video" . Suppose instead of writing Softaware Architecture docs [Architecture Notebook in OpenUP] you can just create a video in which your team explain main architecture on white board....

****WARNING FOR RUP WORKPRODUCTS TEMPLATES:**

DO NOT BECAME A TEMPLATE ZOMBIE.YOU SHOULD NOT FILL EVER PARTS OF IT... YOU SHOULD ASK YOURSELF, WHAT KIND OF BENEFIT WILL I GET BY WRITING THIS...IF YOU HAVE NO VALID ANSWER, DO NOT WRITE... DOCUMENTATION SHOULD HAVE REAL REASONS, DO NOT MAKE DOCUMENTATION JUST FOR "DOCUMENTATION"...**

RUP has rich set of WORK PRODUCTS...So chose minumum of them which you will get most benefit...

For a typical projects generally you will have those Requirements Work Products:

Vision : What we do and Why we do? Agrement of StakeHolders...
Suplemantary Specification [ System-Wide Requirements in OpenUP] : Generally capture non-functional [ which the term i do not like] or "quality" [ which i like"] requirements of system.
Use-Case Model : Capture function requirements as Use-Cases
Glossary : To make concepts clear...

RUP is commercial but OpenUP is not...So you can look OpenUP WORK PRODUCTS templates just to get an idea what kind of info is recorded in them...

Download it from and Eclipse Process Framework Project http://www.eclipse.org/epf/downloads/configurations/pubconfig_downloads.php and start reading from index page:

...-->

...--->

--->

----->

--->

....>.........................................

---->.......................................

Lastly you can find usage of those WORK PRODUCTS in an agile manner at Larman book Applying UML and Patterns...

And again : DO NOT BECAME A TEMPLATE ZOMBIE!!!

回答2:

Try the Rational Unified Process page at Wikipedia for an overview.

The core requirements should be documented in the project description. RUP tends to place a lot of emphasis on "use cases", however it is very important not to lose sight of the original requirements at all levels of detail, because these will answer the "Why?" questions. If the developers only see the uses cases, they will know What they are supposed to build (effectively the functional requirements) but not Why it is required. Unless the developers have easy access to the original analysts, this can cause very serious problems.