Clear Conceptual Thinking

Robert, thank you for your comment! You are remi...

2010-11-01T12:49:24.321+01:00

Robert,

thank you for your comment! You are reminding us that learning is an important part of the SDLC. D'accord.
I also agree to 'we should plan for tangible value.'

Fractions of value is value, by definition, that's why I suggested what I suggested. Of course, you need to have a good understanding what value is, and how to measure it, so that you can

You state: "If user stories get shrunk in ord...

2010-10-31T19:34:08.960+01:00

You state: "If user stories get shrunk in order to fit in a time-box, there's another solution to the problem (besides larger development time-boxes, or using a pull system like Jeff has beautifully laid out): not make a user story the main planning item. How about "fraction of value delivered" instead, in per cent?"

Both the kanban solution Jeff describes (you

Eswaran, thank you! I stopped programming almost...

2010-05-21T12:49:39.282+02:00

Eswaran,

thank you!
I stopped programming almost 15 years ago. So sorry, I don't have any advice on extracting business rules from code other than: When you have them, document them properly ;-)

Cheers,

Rolf

Very neat and clear article on business rules. I o...

2010-05-21T11:31:42.233+02:00

Very neat and clear article on business rules. I often encounter situations where there is a need to extract business rules from existing code. How would you go about it? My thoughts on this at

http://eswarann.wordpress.com/2010/05/21/extracting-business-rules-from-legacy-code-2/

Thanks for the shout out Rolf, I appreciate it. A...

2010-03-03T19:53:16.185+01:00

Thanks for the shout out Rolf, I appreciate it.

And I could not agree more with your powerful method of requirements solicitation: Just ask WHY?

Weera, thanks for commenting on my new layout. I ...

2010-02-28T07:58:10.947+01:00

Weera,

thanks for commenting on my new layout. I enlarged the single post's title a bit.

There's still a problem with the ad display. My idea was to use them as visual seperators; but right now, it looks ugly :-)

Cheers!

Rolf

I feel this layout is hard for reading. I think it...

2010-02-27T08:44:16.963+01:00

I feel this layout is hard for reading. I think it should use different background color for topic's header to separate each topic.

Anyway, I've still like your content. :)

@b_architect

my systems engineer hero? da Vinci is great first ...

2009-12-05T18:45:15.431+01:00

my systems engineer hero?
da Vinci is great first choice,
Philip.McPherson@ntlworld.com
Philip M'Pherson has been a practitioner, educator and
intellectual leader in systems engineering for over 45 years, and
an early and inspirational member of the UK Chapter of INCOSE.
His appreciation for precise mathematical modelling in system
design influenced

Thanks to all commenters, and sorry for the delaye...

2009-10-05T17:53:25.692+02:00

Thanks to all commenters, and sorry for the delayed reaction. I finally figured out how to edit my blog from work.

@Ryan: It certainly is a good idea to define the meaning of the words. I can follow your definitions right away.

@Scott: Agree. It seems to boil down to making a conscious decision about which stakeholder to ignore.

@davd locke: I believe that the &

Julian, thanks for your comment, and for putting...

2009-10-05T17:34:33.080+02:00

Julian,

thanks for your comment, and for putting my words in the BABOK perspective.

You said it is never too late to confirm and clarify your shared understanding of the purpose of the project, and early is better.
I agree, and like to add that we do not automatically move backwards in the project timeline by late clarification, but we risk a considerable amount of

I agree with your assessment at many levels. In my...

2009-10-04T14:50:31.483+02:00

I agree with your assessment at many levels. In my day job I have been working to ingrain the develoment of measurable business- and stakeholder requirements before devloping any level of solution requirements.*

One significant clarification on the ideas here: in your examples and my experience measurable business requirements usually sustain trust rather than create or build it.

Scott, my particular approach is to code for each ...

2009-09-24T01:00:08.568+02:00

Scott, my particular approach is to code for each stakeholder/market using aspect-oriented programming. Every prioritization leaves some shorted. I'm just suggesting the linear programming approach when we are going to short some stakeholders. The real problem is that we will convince ourselves that we are not doing that.

The risk with an LP (linear programming) approach ...

2009-09-23T19:33:33.074+02:00

The risk with an LP (linear programming) approach is that by 'globally optimizing' you risk failing to 'locally optimize' for any one of multiple stakeholders / markets. Coming up "a little bit short" in all you markets can crush you. You may be better off dominating one market at a time.

I use both shall and must in my spec...

2009-09-23T19:30:52.891+02:00

I use both shall and must in my specs, so I disagree that one should be used in every case. The way I distinguish between the two is this:
- shall describes the eventual behaviour of the system (e.g. the system shall require the user to enter an email address)
- must describes a constraint on the system (e.g. the email address must be less than 255 characters

You might look at www.expertchoice.com. They use a...

2009-09-23T17:22:21.916+02:00

You might look at www.expertchoice.com. They use a linear programming approach to stakeholder demands. Prioritize the spaces, put the requirements in those spaces.

Say you end up with a region satisfying four stakeholders with cell AA45 within that space. Put the cell reference in the requirement. Link it, since everyone believes stakeholders change their minds frequently.

Have a preface and number the axillary verbs: 1....

2009-09-23T17:09:38.547+02:00

Have a preface and number the axillary verbs:

1. Vap
2. Dap
3. Slap

It doesn't matter what word you use. The numbers will clarify where globalism and localization confuses.

Well said Ron in short! ofcourse its a very powerf...

2009-09-16T12:08:43.158+02:00

Well said Ron in short!
ofcourse its a very powerful tool when "fed back" into a parametric model. One easy way to estimate using use case points is a template available for download at http://www.docstoc.com/docs/11361962/UseCase-Estimation-Template

Use case point estimating is really powerful and s...

2009-08-24T19:09:04.611+02:00

Use case point estimating is really powerful and surprisingly accurate - especially when the project results are "fed back" into the parametric model.

Another great reason to adopt use cases in your requirements!

Ron Phillips
www.casecomplete.com

Hi Rolf, many thanks for your comments, that's...

2009-07-29T20:12:54.097+02:00

Hi Rolf, many thanks for your comments, that's really kind of you and I appreciate it.

Kelly.

Adrian,

thank you for the flowers! May I q...

2009-04-12T17:05:00.000+02:00

Adrian,

thank you for the flowers! May I quote you?

It's great to have someone who likes the sharing of ideas as much (or even more!) than I do.

Kudos to Adrian Marchis and modernAnalyst,com!

Rolf

Hi Rolf,

You wrote a great article indeed! ...

2009-04-12T01:12:00.000+02:00

Hi Rolf,

You wrote a great article indeed! Great info on Use Cases & Business Rules for Business Analysts.

Keep them coming!

- Adrian

Publisher
ModernAnalyst.com - the leading Business Analyst Community.

Thank you all for your comments. I decided to writ...

2008-12-21T13:21:00.000+01:00

Thank you all for your comments. I decided to write about the phenomenon in the future and hope I can come back to you to work on it.

Has anybody ever experienced really bad consequences from excess functionality?

You know, the scenarios presented here (including mine) seem to be hypothetical.

Thank you!

2008-12-15T06:41:00.000+01:00

Thank you!

Nice!

Kai

2008-12-15T01:34:00.000+01:00

Nice!

Kai

I'd add another category - capabilities that aren'...

2008-12-14T16:01:00.000+01:00

I'd add another category - capabilities that aren't aligned with the goals of the business. Often a little feature gets added because it's easy to do, but it's not aligned with the goals of the project. Leaving it in puts you at risk because customers will likely ask you to expand upon the functionality once you've exposed it to them, which diverts resources away from the your states goals.

Clear Conceptual Thinking

Robert, thank you for your comment! You are remi...

You state: "If user stories get shrunk in ord...

Eswaran, thank you! I stopped programming almost...

Very neat and clear article on business rules. I o...

Thanks for the shout out Rolf, I appreciate it. A...

Weera, thanks for commenting on my new layout. I ...

I feel this layout is hard for reading. I think it...

my systems engineer hero? da Vinci is great first ...

Thanks to all commenters, and sorry for the delaye...

Julian, thanks for your comment, and for putting...

I agree with your assessment at many levels. In my...

Scott, my particular approach is to code for each ...

The risk with an LP (linear programming) approach ...

I use both shall and must in my spec...

You might look at www.expertchoice.com. They use a...

Have a preface and number the axillary verbs: 1....

Well said Ron in short! ofcourse its a very powerf...

Use case point estimating is really powerful and s...

Hi Rolf, many thanks for your comments, that's...

Adrian, thank you for the flowers! May I q...

Hi Rolf,You wrote a great article indeed! ...

Thank you all for your comments. I decided to writ...

Thank you!

Nice!Kai

I'd add another category - capabilities that aren'...

Adrian,

thank you for the flowers! May I q...

Hi Rolf,

You wrote a great article indeed! ...

Nice!

Kai