01-08-2007, 02:02 PM
I have exams coming up (this Wed actually) and its the lovely topic of Systems Design. Or Requirements engineering, or Systems engineering or whatever term you know it as.

I'm highly expecting questions asking me to critically analyse a model, be it RUP, OPEN, VORD or whatever and justify what I say.

Problem is, I don't understand the idea behind Systems Design well enough to do that. I look at all the models and yes they use different terms and yes their diagrams are different... But ultimately, what's the practical difference? They all do the same thing...

Gather requirements
Design architecture
Implement system
Test it
Distribute it to user

Can anyone shed any light on this?

01-12-2007, 12:32 PM
How your exams go?

01-12-2007, 01:11 PM
Head in a car door... slamming hard.

01-12-2007, 01:14 PM
OUCH!! Sorry. :(

01-12-2007, 05:32 PM
I'm sorry Scott.

You know, when you made your original post, I got kinda excited. After all, this whole "software design process" is what my whole career is supposed to be about.

But you started throwing out these strange methodologies (VORD, RUP, OPEN) and I wasn't familiar with any of them. I spent about an hour trying to research them to find out what they are all about. All I really got was that RUP is just Rational's proprietary spin on the whole use case / XML perspective of gathering software requirements. VORD focuses on system requirements rather than software requirements and supposedly is all about gathering things from different points of view.

In the end I was kinda stymied. While I agree that the gathering, documentation, prioritization, and management of requirements is quite possibly the single most important part of developing a product, these specific methods seemed so tainted by professional interest (RUP) or so caught up in esoteric academic theoretic babble (VORD) that they were next to meaningless in a practical business setting.

And I never did find out what OPEN was.

01-13-2007, 04:21 AM
OPEN, Object Oriented Process and Environment Notation.

Idea behind it is that instead of sticking to one 'process' of activities. you use objects to define the activities, tasks required and techniques to do it. You essentially break down the entire lifecycle into a bunch of components and reorganise em, drop em or add em as you need them.


3 Questions on the paper, I answered 2. Here's the two.

1. From a planning point of view, a systems engineering model can be used to define the different types of activities that are necessary to complete a project.

a) Outline why a simple linear process model has shortcomings and explain how such a model can be re-organised to produce a layered model. Identify each of its sub-processes, explaining their use and identify the documents which are produced. Hence, or otherwise, discuss how the model needs to change for the development of large or complex systems.

b) Evaluate the use of 'stage gates' in systems engineering to control risk.

2. A software company has employed you as a systems engineering consultant. To date the company has not had a formal approach to requirements engineering.

a) What arguments would you give the company to justify the introduction of a formal approach to requirements engineering? VORD and CORE are two possible methods that you could recommend the company to use. Explain and justify which method you would recommend for the company?

b) Provide the company with an assessment of the DOORS requirements management tool.

01-13-2007, 07:55 AM
b) Provide the company with an assessment of the DOORS requirements management tool.

Good tool to use for various types of requirements (software, electrical, mechanical, system).
Integrates well with Microsoft office products.

Expensive (6 figures for a few floating licenses).
Difficult to set up and maintain (plan for at least one full time admin for this tool alone).
Big learning curve for users (plan for significant user training).

Been there.