topsyWidgetPreload({ “url”: “http%3A%2F%2Ftynerblain.com%2Fblog%2F2006%2F01%2F25%2Fa-requirements-documentation-mistake%2F”, “style”: “big”, “title”: “A requirements documentation mistake” }); Learn from an early mistake of mine At a previous employer, the first time I played the role of requirements manager (technically, program manager – with responsibility for the functional spec), I made a bunch of mistakes – this post is about one of [...]
Category Archives: Writing
Posted in Communication, Requirements, Requirements management software, Software requirements specification, Writing
Tagged conway's law, documentation, FRS, functional requirements specification, managing data, market requirements document, MRD, PRD, product requirements document, requirements spec, requirements specification, software requirements specification, SRS
6 Comments
Are people reading your requirements? A blogversation.
topsyWidgetPreload({ “url”: “http%3A%2F%2Ftynerblain.com%2Fblog%2F2006%2F01%2F11%2Fare-people-reading-your-requirements-a-blogversation%2F”, “style”: “big”, “title”: “Are people reading your requirements? A blogversation.” }); Tony just put up a post at Seilevel’s blog on making sure your spec is reviewed. Kent Newsome recently posted about starting cross-blog conversations here, possibly inspired by Amy Gahran’s post about it here. Tony’s post is a great topic to [...]
Readability and Requirements
topsyWidgetPreload({ “url”: “http%3A%2F%2Ftynerblain.com%2Fblog%2F2005%2F12%2F30%2Freadability-and-requirements%2F”, “style”: “big”, “title”: “Readability and Requirements” }); Thanks to the download squad for pointing me at the Juicy Studio: Readability Test! You can go to Juicy Studio’s site, and calculate the reading level of any URL. Of the multiple analyses provided, the Gunning Fog index is the easiest result to read – [...]
Secret decoder ring
topsyWidgetPreload({ “url”: “http%3A%2F%2Ftynerblain.com%2Fblog%2F2005%2F12%2F15%2Fsecret-decoder-ring%2F”, “style”: “big”, “title”: “Secret decoder ring” }); I’m having a little trouble reading the spec – I left my secret decoder ring at home! Ever hear that before? A set of requirements that makes perfect sense to one team member can be completely unintelligible to others. Requirements written in business-speak, or full [...]
Improve your writing with graphics!
topsyWidgetPreload({ “url”: “http%3A%2F%2Ftynerblain.com%2Fblog%2F2005%2F12%2F12%2Fimprove-your-writing-with-graphics%2F”, “style”: “big”, “title”: “Improve your writing with graphics!” }); I attended training on making compelling presentations last year – and one thing that was stressed was the use of imagery to drive points home. Although there have been images in my posts to date, they have been utilitarian – not sources of [...]
A Picture Is Worth A Thousand Requirements
Object oriented analysis and design (OOA/OOD) is a technique used to gather requirements and develop software, as an alternative to more traditional text-based techniques.
OOA allows for clarity of communication, by creating descriptive and unambiguous documentation of requirements. It comes with a great big giant caveat –
Posted in Communication, Requirements, Requirements gathering, Writing
Tagged business requirements, managing data, modeling requirements, modeling software requirements, ooa ood, ooa requirements, requirements elicitation, requirements model, requirements modeling, software requirements gathering
1 Comment
Intimate Domains – navigating areas of expertise
topsyWidgetPreload({ “url”: “http%3A%2F%2Ftynerblain.com%2Fblog%2F2005%2F12%2F02%2Fintimate-domains-%25e2%2580%2593-navigating-areas-of-expertise%2F”, “style”: “big”, “title”: “Intimate Domains – navigating areas of expertise” }); People who elicit and manage requirements – product managers, business analysts, program managers, and others – also orchestrate and communicate with their clients. In an enterprise software project, the requirements manager (RM from here on out) has to communicate with people [...]
Stop Wasting Your Time – Don’t Bother Writing Functional Specs
Don’t do it. Don’t use a functional spec to get superficial agreements and navigate the beurocracy that accompanies large projects. Don’t validate the specification trivially. Don’t deploy with a waterfall process (the spec is done, whew, now – on to design) and never revisit the spec. Don’t work with new developers, or remote developers, or anyone else who doesn’t have the context of direct eyeball-to-eyeball conversations with the customers. Also don’t hire any programmers without complete domain expertise in the customer’s business
Posted in Requirements, Software requirements specification, Writing
Tagged baselining, extreme programming, FRS, functional spec, functional specification, kent beck, managing data, Requirements, requirments document, software requirements specification, software specification, SRS, waterfall process
Leave a comment
Latest Articles
Comments on all Articles
