Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - sargasso

Pages: 1 ... 88 89 [90] 91 92 ... 94
Uml Process / Re: Categorizing Requirements
« on: March 08, 2004, 03:06:01 pm »

RUP discusses FURPS+ in some depth.  See "Concepts: Requirements"

The RUP rerence is
GRA92 Robert Grady 1992. Practical Software Metrics for Project Management and Process Improvement. Prentice-Hall.

Also Wiegers book mentions it (Wiegers is THE requirements book IMO :) )

Uml Process / Re: Categorizing Requirements
« on: March 07, 2004, 03:57:00 pm »
Re 1. We let projects define their own categories for requirements.  However, they are provided with the following as a “starting” point and few have needed to go much further except for some specific technical environment related specializations.

Functional requirements
Functionalusage requirement, something the system does
Validationsome specific validation that must occur
Displayuser has an express desire that information is presented (screen or report) in a particular manner
Databusiness requires that specific data be recorded (persisted) by or through the system
Supplementary requirements
Performancedemonstrable business need that the system response be x at a specific instance
Constraintany requirement that constrains the design of the system in some way.

Other than the above, I occasionally come across projects that have justifiable needs to add some specific categories on specific projects. For example, they may break constraint up further if the client has specified a zillion design constraints that the project needs to review and justify.

We have deliberately tried to keep the number of categories small while allowing the projects to extend the categories where it will assists rather than hinder the progress.

Re 3. In the main, “large” functional requirements have tended to map to a single use case.  In other words, “the system shall provide a function to create a new customer account” pretty obviously maps to “Create Customer Account”. Other use cases arise through normal requirements gathering and analysis work.

We strongly encourage all projects to record business requirements as “external requirements”.  These can easily be related to one or more impacted use cases as <<realizations>> and EA takes care of the rest.

Re 2: We encourage projects to adopt the following process for requirements gathering and analyses:
    [1]Initially just record the requirement in the top level of either the Functional or Supplementary requirements models.
    [2]At frequent group reviews, the EA Type attribute for new/changed requirements is agreed by the project team and set in the model.
    [3]As the requirements model matures, suitable “formal” package structuring for the requirements set appears – we do not insists on any specific structure below the model level – the best structure is determined by agreement between the teams responsible for the design, development and support of the specific system.

The structure of the template we provide projects with for using UML is as follows:


Specifically, for the system requirements, it is

(The project determines package structure to suit the system here)
USE CASE model
UI DESIGN packages…

What (all) the above has allowed us to do is to have a fairly consistent approach across all projects in the organization, allow the necessary degree of flexibility for specific projects and, most importantly, comply with the KISS principal.

Projects use the packaging structure below the model level to achieve objectives specific to the system and project.  For example, one project that has a large user type or business type base may break up requirements into SME packages thus letting each of the SME’s approve their requirements as a small set rather than presenting them with the tome of all the requirements for the system.  Another project, that has cross technology scope (say a Webshere/DB2 based distributed web app) may break up the packages by technology base so their architects and designers are driven by the requirements specific to their technology area.  We also encourage the projects to consider running multiple model structures if that will add value.  In that scenario, requirements elements are recorded in an agreed “base” structure below the model and other structures re-represent the requirements in a different manner.  So a particvular system structure may look something like the following:

FORMAL REQUIREMENTS (base) sub model

Bit of a rave, but I hope that gives you some ideas.

Uml Process / Re: What point to make a deal with the client?
« on: March 08, 2004, 03:29:47 pm »
Analogies to house construction do not realy hold! In a house usually EVERYTHING is planned and determined and never changes during the construction process. If you want changes while the house is under construction it gets REALLY expensive. Thats why an architect, the guy needed in the planning phase, is expensive.

The analogy holds extremely well.  As you say, in construction everything is planned - and that is my point - why do we, in IT, still try to give estimates in the void at all.  It is not difficult - its actually impossible.  Hence my variance factors in the above table.

If construction used the IT approach: -

Client: "Mr Builder, how much will you charge me to build a four bedroom house?"
Builder: (Thinks)Last 4BR I did cost me $45000 and I quoted $38000 for it - so 45 + 7 for the recovery + 30% margin= 66ish(/thinks)
Builder: "Without analysing what you want I'd say in the order of $66000"
Client: "Thats too much - I only want to spend $38000 and I need it finished next week before my mother in law arrives"
Builder: "Not a problem, I'll get started laying the foundations this afternoon"

In my variance based approach:

Client: "Mr Builder, how much will you charge me to build a four bedroom house?"
Builder: "Typically a $BR can cost anywhere between $45000 and $225000 I'd say depending on what you want exactly"


p.s. If you reckon house design requirements dont change during construction your obciously not married! ;)

Uml Process / Re: What point to make a deal with the client?
« on: March 04, 2004, 02:35:56 pm »
Maybe I'm blessed, but everywhere I've worked in the last 10 years has preferred to fund a known requirements analysis phase prior to committing to a build phase.
The risk to the consumer in funding a project from go to whoah (woe?) is much higher than doing it in two phases. (refer back to the table).  
Although the developer is at risk in providing a fixed price for a system based on unclear or ill defined requirements the risk to the consumer is much higher.

Consider the construction industry - if I ask a builder to give me a quote and build "a house", what am I likely to end up with.  On the other hand, if I get an architect to consult me on the design of the house that I want, then i'm much more likely to end up with the house I had in mind.

Uml Process / Re: What point to make a deal with the client?
« on: March 03, 2004, 02:05:19 pm »
The following table shows the variance to reality of software development cost estimates made at various points in the design cycle.

Estimation based onEstimation TechniqueVariance
Unclear RequirementsGuess+-400%
Use case modelsUsecase points+-100%
Signed off reqtsUsecase points+-50%
DesignProject plan+-50%

Show this table to the sales people - tell them its industry standard!

Uml Process / Re: "Alternative" requirements
« on: March 05, 2004, 04:15:51 pm »

This looks like its the easiest way to achieve what I want.  I'll keep you posted


P.S. Geoff, if your listening what I need is one of the following alternative requirements
A) control drag'n'drop that can shallow copy an entire view into a new root node, or
B) a macro language that I can use to script copying parts of a structure between views/root nodes.

Any time on Monday morning will be fine!  ;D

Uml Process / Re: "Alternative" requirements
« on: March 05, 2004, 03:53:54 pm »
A bit more information that I didn't put into the original post...

The system - in the main - has already been designed and built.  IOW, we are currently at release 0.9beta

There were some unresolved implementation items deferred from the original design phase as, not unreasonably, they had some issues and did not impact on the core system material too much!  As the example above indicates they tend to be implementation choices where the true user requirement is unclear because they do not understand the issues.

My core issue is that the design - a huge EA model - could easily be disturbed while we work out these issues and everyone will get too confused.

I have had an idea overnight that it might be possible to use new Project Root Nodes to investigate the alternatives.  I'll give it a go and see if it helps.  It would be nice if we could make the original root node elements read only though!.

It appears that the latter releases of EA support "localised" colouring of elements at the diagram level. I have not investigated how far this goes, i.e. does it apply to all models.  What we might be able to do is use colours to highlight the impacted elements by alternative!  Here's hoping.


Uml Process / "Alternative" requirements
« on: March 04, 2004, 05:32:41 pm »
I have not come across this before and thought I would put it to you folks for some input.

We have situation where the client has specified a set of alternative requirements and asked for input as to the impacts and costs of each alternative.

By way of example, one of the primary requirements is that a webserver failover feature be implemented that includes the need to mirror some active files between two file systems.

The (very reasonable) client has suggested that we could mirror at two levels
- total mirroring whereby the synchronization is done at a periodicity less than the heartbeat period for the failover
- occasional mirroring done at a less frequent interval, say every 30 minutes.

They have asked for infomational material regarding the alternatives in order to make a decision on which way they want to go.

My problem is "how to model alternative requirments".  Each of the scenarios above has implications that affect subsequent requirements and on the use case, component and deployment models.

b.t.w. we are using external requirments at this stage of the project.

Has anyone had a similar experience and can you offer your "best way" to build a set of models to represent the impact of the alternatives?


Uml Process / Re: UML 2.0 and Use Case Generalizations
« on: March 01, 2004, 02:54:37 pm »
Since use cases are a classifier and classifiers can be generalised and specialised then use cases can use the generalises relationship.

Although the text does not seem to mention it, diagram 406 definitiely shows use case generalizations.


Uml Process / Re: Analysis, Boundary/Control/Entity self message
« on: February 26, 2004, 06:27:34 pm »

Uml Process / Re: Analysis, Boundary/Control/Entity self message
« on: February 26, 2004, 02:53:25 pm »

p.s.  In doing the previous, several times what we thought was client side achievable, needed to be done on the server side.  i.e. the business was able to pick up our misunderstandings!

Uml Process / Re: Analysis, Boundary/Control/Entity self message
« on: February 26, 2004, 02:50:20 pm »

To some extent, although it may not be optimal UML, we use a similar approach here in analysis to decide at a conceptual level what can be handled on the client side and what actions need to be passed back to the server side for action.  As we dont have the business side technical people trained on UML past the use cases, activity models, and other "top level" UML tachniques we model behaviour that they need to understand using MVC (or OOSE if you prefer) collaboration models  - typically using boundary and entity objects only.

Consider, as a simple example, a login form.  Two textboxes and two buttons.  The "requirements" for validating the form are:
  • user name must be entered
  • password must be entered
  • username password pair must be valid/known

The first two can be resolved at the client end, without invoking server traffic, using client side scripts.  Obviously the third requires a submit/POST and server side validation.

We use collaboration diags to show the business what actions are occuring on the client side and what on the server.  (Obviously our examples are much more complex than this.)

Make sense?


Uml Process / Re: Analysis, Boundary/Control/Entity self message
« on: February 26, 2004, 02:36:56 pm »

The profile is based on Conallen's original work, so it may differ slightly from the book.

However, I dont have the same problem you are describing?  Whereas you are using an analysis diagram, I use a collaboration diagram.  But I just tried the same thing using an analysis diagram with no problem.

Are you creating the self association link first?


Uml Process / Collaboration Messages advice
« on: February 17, 2004, 09:12:27 pm »
According to Iconix, actors should not have associations with or pass messages to controller objects.

I am trying to sort out in my own mind how best to model active web pages.

The user sends a GET message to the web server listener which responds with a html page.  Now, on that page is a form that has a submit action of POST.  The server listener is supposed to receive that request, process it and generate a response page via its page engine.

It appears to me, that either I have to include the browser and webserver listener which are components not objects in the collaboration chain, or the user can send a message to a controller (the ASP script)?

Has anyone got any good ideas?

Uml Process / Re: Connallen breaking the rules? -UML for Web-
« on: February 15, 2004, 02:52:48 pm »

I have not read his book, but having seen other works by the gentleman I would venture to say that his views are taken more from the "designer" point rather than the "analyst".  

That is, I would expect that he is not looking at use cases as a means to synthesize a structured business view from which to derive requirements and then move into a design phase.  His works tend to "presume" that the requirements have been done and a solution architecture (usually ASP :-) ) has been decided.  Thuis his use of use cases is as a framework to hang design components on.

In thses situations, (requirements and architecture already decided), we too just use the use cases as a scaffold to hang the design around.  We tend to try and pitch it more at the business level then he does, so that we can handle system testing and deployment in the same framework.

Remember, UML is a "simple but rich" notation that lets the audience all talk the same lanuage about the system.  Therefore, if you are primarliy concerned with explaining the design and implementation of web applications and your audience is intended to be the technical developers of those applications then it is acceptable, I suppose, to use use cases in such a manner.

I also note that given a "stateless" architecture such as web applications, the use cases may indeed be closer to a CRUD model than most stateful systems.

Pages: 1 ... 88 89 [90] 91 92 ... 94