Topic
  • 2 replies
  • Latest Post - ‏2013-02-15T06:16:30Z by SystemAdmin
SystemAdmin
SystemAdmin
3545 Posts

Pinned topic RUP without Use Cases?

‏2013-02-14T17:12:21Z |
Hi,

I am investigating the possibility of using RUP to manage a project of building an internal Integration Service Bus.
RUP with its architecture-centric and technical risk focus approach, is a great fit.
However, RUP is driven by Use Cases. Of course such types of projects have no people interacting with them, so there are no use cases. How would RUP be applied in this case? Can I simply omit use cases and as long as i can model my requirements then i can use RUP?
Thanks.
Updated on 2013-02-15T06:16:30Z at 2013-02-15T06:16:30Z by SystemAdmin
  • BruceMacIsaac
    BruceMacIsaac
    19 Posts

    Re: RUP without Use Cases?

    ‏2013-02-15T00:45:12Z  
    Yes, you can certainly use RUP without use cases. It wouldn't be "standard RUP", since RUP is a configuration that includes use cases, architecture, and so on. However, we encourage customers to create configurations that match their needs. So if you have another way to specify requirements, that's fine.

    Using the IBM Practices library, we have a "slot" called "Technical Specification". When you want to use some other way than use cases to specify requirements, you associate your requirements artifacts with this slot, and then they are logically input to practices that take this slot as an input. If you look at the practices "user story driven development" and "use case driven development" you can see examples of how this is done.
  • SystemAdmin
    SystemAdmin
    3545 Posts

    Re: RUP without Use Cases?

    ‏2013-02-15T06:16:30Z  
    Yes, you can certainly use RUP without use cases. It wouldn't be "standard RUP", since RUP is a configuration that includes use cases, architecture, and so on. However, we encourage customers to create configurations that match their needs. So if you have another way to specify requirements, that's fine.

    Using the IBM Practices library, we have a "slot" called "Technical Specification". When you want to use some other way than use cases to specify requirements, you associate your requirements artifacts with this slot, and then they are logically input to practices that take this slot as an input. If you look at the practices "user story driven development" and "use case driven development" you can see examples of how this is done.
    great...that's the answer i was hoping for
    thanks.