Coding the Architecture - functionalrequirements tag

Who's paying for this?

Fri, 07 Dec 2007 10:43:53 GMT

I like working with users as they often give really good feedback. They're the ones who have to live with the software every day so tend to be very clear about how it helps/hinders their work.

Is it naive to think that making users happy by meeting their requirements is the primary goal of a software delivery, though? In my experience, which is not in COTS software development, the end users are not paying for the software - their boss is. Yet we often grant users great import, perhaps because their feedback is more immediate and tangible. Granted, it is unlikely that giving users unusable software is going to prove successful. Conversely, giving users exactly what they want is also unlikely to be a success. For a start, it could well prove financially prohibitive (eg, technically difficult)!

I consider one of my responsibilities as an architect that of keeping delivery focused on what matters. Sometimes this may mean giving the users what they want, sometimes it may mean telling the users what they're getting (and helping smooth the transition). After all, change isn't always just about transparently replacing the technology.

I'm sure I'm not the only person who's worked on software that has delivered what users wanted but has never seen the light of day. Were the users wrong or were we simply speaking to the wrong people?

Mastering the Requirements Process

Tue, 25 Apr 2006 20:19:20 GMT

I've just received a copy of Addison-Wesley's "Mastering the Requirements Process" 2nd Edition to review over the next few weeks. The blurb says:

Mastering the Requirements Process, Second Edition, sets out an industry-proven process for gathering and verifying requirements with an eye toward today's agile development environments. In this total update of the bestselling guide, the authors show how to discover precisely what the customer wants and needs while doing the minimum requirements work according to the project's level of agility.

I'll be reading it over the next couple of weeks and posting a review after that. Please feel free to post any specific questions and I'll try to answer them in the review.

Give the user what they want...

Fri, 17 Mar 2006 16:02:28 GMT

I used to subscribe to the school of thought that you should write, or at least design, your system solidly and then build your user interface(s) on top of this sound foundation. After all, it's got to work before you can use it, right?

I'm not so sure anymore, though this is mitigated somewhat by an iterative process. I've more recently shifted towards the notion that each function must be usable before it can be used. After all, its main purpose in life is to be used, not to be strategic/beautiful/standard/optimal, right?

People, particularly developers, tend to dismiss the user interface as being the "front-end" to the application, simply adapting between business function and user. This is only really true once it is complete; during development the UI is defining and refining the business functions - it is part of the development process. When implementing user interface first it is often the architectural assumptions that get changed since they don't fully support the desired functionality. This is a good thing - it is refining the architecture and making it fit for purpose, the purpose being to serve the user.

Of course you're stuck trying to balance functional and non-functional requirements - just remember that the users carry a lot more weight than you might first think! If the end users don't want to use your application you'll struggle to get it adopted whereas if the end users do want to use it they'll give the project real inertia, biting your arm off for new features.

Also, whilst it may seem a bit Machiavellian, it's quite easy (and sometimes fun) to ride an unrelated architectural improvement in on the back of some new user functionality. The development effort's got impetus so why not make the most of it and champion your own requirements?

The overall quality of your system should improve with the addition of functionality.

The development of new functionality requires the refactoring of related code, thereby improving it. This development also facilitates the refactoring of unrelated code - an opportunity worth taking!