Non-functional requirements seem to be a really hot topic, I suspect that my blog is getting a lot of hits because there’s not a lot out there on the subject. I may be going against what I’ve already put on the Project 21 page but I think I have a growing feeling that non-functional requirements should be related to the ‘Ends’ and that Functional requirements are related to the ‘Means’. Looking at the OMG Business Motivation Model (BMM) tends to confirm this and gives a much firmer logical basis for non-functional requirements. It probably also indicates that we should be calling them something else like ‘Business Requirements’, which kind of fits in with having ‘Business Use Cases’ with ‘Functional Requirements’, that make those Business requirements happen. I kind of like having BMM compliant requirements, because that just says what they are and how they relate, not how you express them. So if you wanted to express requirements in RDF or some ontological form that would fit in quite well. It has some implications for traceability as well, if a function cannot be traced back to a non-functional requirement why would it be needed? I’m going to back track and redo requirements in the next few weeks, this should be fun.
Month: May 2009
Is this an Agile methodology?
Working on the design process makes me think that Project 21 sometimes looks like Agile and sometimes not, depending on which stage it is at. Considering the Agile and the Business Analyst are often at odds, this seems to be perfectly normal. Just by trying to separate the analysis of the problem from the design of the solution exposes the Agile dichotomy; is it possible to design a solution without analyzing the problem? The answer must be a definite maybe, but for any non-trivial problem analysis and design are needed to ensure that the solution solves the problem. Project management methodologies tend to go around this issue by being prescriptive about eliciting requirements and signing off, yet Agile addresses the issue of the requirement developing with the solution.
To a degree both approaches have their merits, if the user can state business requirements at a high level these can be quantified in the development cycle. The design phase can say ‘we address these broad requirements’, and development can refine the detailed requirement. I’m not going to brand Project 21 as purely an Agile methodology, it is an adaptable methodology.