home

merrickp's blog

Radical views on story telling

I started off as a nay-sayer and doubter around user stories in the Agile/Scrum space. I haven't completely revised that view, but kind of. I like the way stories let people work together. Stories are so much friendlier as a metaphor for discussing requirements. Everybody's got a story to tell - right. Of course. Everybody's got a voice and they want to be heard. I like that. It's inclusive.

A pattern language for uncovering business requirements

Hello again,

When i did my PhD I came up with a requirements pattern language that I still use. It's really good for database driven applications and gives the analyst a running start on producing a first specification. It's at the heart of my project management method (PrinceLite) that joins up management with engineering. You can get the paper at www.princelite.co.uk/downloads.cfm. You have to sign up, but don't be shy.

Cheers,

Peter

Show me don't tell me. My take on layered unambiguous business requirement representation

Hello all,

Well, work on the PrinceLite proposition continues apace. I can offer something I think is workwhile and want to let people know. I've posted my versions of stripped down (almost elegant) project brief and BRS templates along with a worked case study from a system I specified a couple of years ago (that delivered successfully - thank you for asking...)

So, I'm really interested in layered requirements according to outline, high level, mid level and possibly low level requirements. If this interests you too (and why wouldn't it?) then have a look at www.princelite.co.uk/downloads.cfm. You'll have to sign up to download the templates though so I know who you are (tell the truth!).

Cheers

Peter

    Sponsored Announcements & Special Offers

view counter

Whitepaper from HP - Why Focus on Requirements Definition Management in the Application Lifecycle?

Increasingly, smart businesses are looking much closer at requirements definition (RD) and requirements management (RM) (sometimes grouped together under the Gartner-coined phrase, requirements definition management (RDM)) to streamline the entire application lifecycle. Why? Because systematic and effective RDM captures software defects earlier in the lifecycle, and it reduces the overall likelihood that defects will be introduced. That’s important. How important? According to one study, the cost to fix a defect after delivery is more than 100 times the cost to fix it in the requirement and design phase. No business wants to be hit with that bill. Now to add to this the growing interest in agile development techniques as a way to deliver higher quality applications and we have an interesting recipe for success.

Download a Free Copy

view counter
© 2007-2010 Requirements Networking Group All rights reserved. contact | advertise | privacy
Requirements Networking Group