- July 6, 2008
- Posted by: admin
- Categories: Agile Applications, Agile Project Management, Blog, Communication, Enterprise Agility, Requirement Analysis
Are Software Artifacts like an inventory getting stale?
It is important to understand that there’re no perfect business requirement specification – and any specification you make HAS to change even days or weeks after you’ve completed a detailed analysis phase. A very detailed upfront requirement specification is analogous to storing high upfront inventory in a warehouse getting stale every passing day.
Does Just In-Time Requirement Analysis save cost and increase output?
Given this fact, you need to apply a concept called ‘Just In Time Requirement Analysis’. This however requires a candid and upfront sharing of the business domain, opportunities and threats with all stakeholders involved.
Having a high level business concept, architecture and scope is essential. However, brainstorming throughout the development life-cycle will then result in
just-in-time requirements which are most relevant to the business. Supplement this JIT requirement analysis with a solid high fidelity prototype which can serve as a strong visual and contextual communication tool for the requirements between the users and developers.
High fidelity Prototype OR Detailed Documentaion?
Picture is worth thousand words… and a high fidelity prototype is worth more than tens of specification documents. A prototype which all stakeholders can touch feel and own will solve most of the issues related to requirement failures and change management chores. Change will be accepted and owned more easily and traced more visually.
Is Just-In-Time Just Right?
Just-in-Time Requirements analysis significantly reduces project risk and shortens development time. It ensures the most important parts of a system – as defined by the business stakeholders are being worked on at any given point in time and only defines requirements when they are needed. Yes, this is a paradigm shift from a more sequential waterfall-based approach.
JIT requirement analysis is one of the corner-stones of agile development philosophy. For more details read ‘Requirements Modeling’ whitepaper our Business Research team has prepared.
Quite convincing I must say.
Our company has been working on Waterfall Model since 15 years. In the beginning the requirements gathering process was quite sound. But as our partners have gradually modified their business model we are facing hurdles to keep up with our model. Also almost all business’s today have a very fluid set of process that require time to time changes.
Just in time requirements gathering might be the answer to catch up with speed and dynamism in the present world.
As interesting as the concept is of ‘JIT RS’, the activity will require the expertise in analysis and modeling.However If it can be implemented successfully the client will be the happiest involved as faster delieveries can be produced and chances of complete failure can be reduced.
We are currently implementing upfront requirement modeling for some medium sized projects for test run and so far its been beneficial,giving us more power on resource scheduling and utilization as well as on the budgeting grounds. This is definetely a workable concept.
I have been outsourcing for over 10 years now, I have outsourced in India, Pakistan, Russia.
RAD, Waterfall, etc… A challenge no matter what approach you take.
JIT is the most flexible way I have found in my 22+ years delivering software solutions.
The key to success in this model in my opinion is to get the concept into the heads of the stakeholders early in the cycle that they are not part of a long drawn out process and their input will count all along the way. Having a long drawn out process unfortunately in the past allowed stakeholders and users to assume someone was managing their interests ( a great way to hide from responsibility and ownership). Only to be surprised when Beta testing starts that what they assumed was being developed was not being developed…. with Agile development, a user can clearly see if what they asked for is actually what is being programmed.
Outsourcing enables the stakeholders to easily “blame” the outsourcing model. And if older development life cycle models are used, nobody will be happy and “outsourcing” becomes a bad word.
Having a constant managed review cycle keeps everyone happy and engaged.
Old school requirements analysis ways are good when you are building big systems. However in year or two the needs might have changed, since business environment has changed. So even the best requirements engineer won’t be able to help.
Other option is using agile methods and deliver incremental functionality on weekly/monthly basis. This way you can be sure, that clients needs can be addressed in much more flexible way.
What you describe would not be consider requirements engineering IMHO. I would liken your activities to building a prototype without requiremetns to determine the requirements from the working model. In other words, building a house and determining whether it suites your needs. Then constantly changing it until it does. This drives up cost and lengthens the process.
In a typical requirements engineering discipline, there is a decomposition which refines the requirements as you decompose the system layers. There is a verification process that ensure that the proper level of analysis is completed to ensure the system model is verfied against the “real-world” environment and model. Trade-off studies are performed at each level of the system level decomposition to ensure that when sub-systems are assembled into a system and the testing is performed, lower level requirements can be prioritized and weighted properly to the best system level characteristics. This is the validation process. So, you have verification and validation. At any time, you can alter te requirements but an analysis of impact must be done to ensure all integrated requirements are not adversely impacted.
For dynamic systems, use case mapping is a technic to use to better extract the requirements and refine the requirements through the system level decomposition. You can also perform requirements prototyping that helps refine the requirements and elicit better requirements. Here is a definition:
REQUIREMENTS PROTOTYPING
During this task, the RE teams generate requirements engineering prototypes. This task typically includes the following subtasks:
• Produce one or more requirements prototypes (e.g., paper or wireframe
prototypes of user interfaces or executable models).
• Evaluate these prototypes. This may involve analysis of static prototypes or execution and evaluation of dynamic prototypes.
• Use these prototypes to:
– Help identify new requirements such as functional, data, and quality
requirements regarding user interfaces.
– Better understand existing requirements.
– Identify defects in the existing requirements that drove the development of
these prototypes.
– Support the analysis of these requirements.
Below is brief description of requirements engineering:
In the Software Engineering Body of Knowledge (SWEBOK) [Sawyer 01], requirements engineering is described using a four-step process model, including requirements elicitation, analysis and negotiation, documentation, and validation. An output of this process is the set of agreed-upon requirements. Requirements elicitation is described as the first stage in building an understanding of the problem that the software is required to solve. Requirements analysis has to do with the process of analyzing requirements to detect and resolve conflicts among requirements, discover the bounds of the system and how it must interact with its environment, and elaborate user requirements to software requirements. Requirements negotiation has to do with resolving conflicts, such as those that might occur between stakeholders, or between requirements and resources. Validation is concerned with checks for
omission, conflicting requirements, and ambiguities.
I would strongly suggest that a requirements engineer, someone with extensive experience in requirements development, be hired to ensure that the expectation on both parties is properly set and the investment cost for the system is not exploding. I would also recommend contacting someone from INCOSE to assist you in your requirements engineering process.
Actually, it feels a bit odd. JIT Requirements can possibly lead to unfocused development and in the longer run to inflexible structure.
High level design should be done, if the system has complexity above average. The way it is being described here, I would only recommend for smaller projects with not so many stakeholders involved, otherwise you are programming your project to mess and chaos.
My company helps our clients manage the ever-changing business environment by modeling all aspects of the project, and code-generating a substantial amount of the application.
Using our approach, Requirements are modeled using UML as are User Stories, User Interfaces, Business Objects/Web Services (the middle tier), the Database, as well as Test Cases. Since all of these artifacts are stored in a single database, we’re able to create complete traceability between them. So, I can answer questions like “If I change THIS requirement, what parts of the system are impacted”.
Having all of the information stored in a database (as opposed to Word documents and Visio) allows our clients to code generate a substantial amount of the application directly from the model, including the user interface, user interface to business layer bindings, certain business rules, database schema definitions, business object to database persistence, etc.
Combined with an agile project methodology, modeling and code generation provide the flexibility needed to keep up with today’s rapidly changing business environment.
I would somewhat disagree with the first answer. That way is good when you are building big system. However in year or two the needs might have changed, since business environment has changed. So even the best requirements engineer won’t be able to help.
Other option is using agile methods and deliver incremental functionality on weekly/monthly basis. This way you can be sure, that clients needs can be addressed in much more flexible way.
You pose quite an interesting question. Around here, and specially when dealing with the end, non-technical, customer we usually try to understand the following levels, regarding what the customer…
1) … is asking for
2) … really wants, despite what it asks for
3) … really needs, despite what it wants
Dealing with these 3 levels and pretending to address 1) while actually addressing 2 and 3 is not always easy. Funny enough, our pet at the office is called JITRA (we had to materialize it somehow).
Regarding Planning software applications, we obviously split the timeline into distinct phases. At each phase, we usually assign a set of goals, not features, but in terms of “what tasks will be doable at this point”. We have taught the development team to think slightly in terms of marketing, not in terms of the dreaded featuritis, but in terms of what actual value the software will achieve at each phase. As you reach the end of each phase, you specify the smaller details of the next fase – you already know what you want to achieve, you just plan “how”.
Technically, we rely on early releases and on building a functional GUI with “empty slots” or NIY wherever relevant for the comprehension of the application’s behaviour. Also, for non-web applications, a push/pull automatic update system allows us to keep the beta testers (or early customers) involved and always up to date.
In answering your question more directly, I believe in order to deliver a custom solution that everyone will be pleased, one has to grow the solution iteratively. The ages old method of writing a specifications guide and then retreating to a cave to implement it simply doesn’t work, or doesn’t yield results comparable to a more dynamic approach.
It’s late and my writing skills are abandoning me, so thanks for raising the question, I’ll enjoy reading other’s replies here and at the blog you mention.
Regards,
In my experience, JIT requirements can be just as good or bad as methods that take longer.
As a PMP, I have to shudder at a fluid definition of requirements that changes until the client is satisfied – I refer to this as scope creep.
What works best for me is a BA who is skilled at UML modeling – writing use cases that are geared to how the client works, breaking the system down into building blocks, and being able to communicate between business and technology. If you have properly modeled the UML, then you can write modular code that will work later; with easy iterative revisions if needed. By focusing on those use cases that are most important, you are developing a workable module that can then be expanded to add additional features.
Most of the system problems I have seen come from people designing from a menu/button oriented approach – I want to click on this and have this happen; instead of examining the underlying work flow and developing an interface that matches it.
Hi Ali,
Just see how WIP cost analysis effects product costing,In another question I have answered,
JIT, is to reduce the WIP costs and to meet the design change requirements which would effect the proto type, Normally the product development phase we use JIT, how ever this is also useful when manufacturing products using 1.high valued raw material to reduce WIP costs, and 2. raw mateiela easily available in market.
In development of proto type is taken up as a RD project and after closure of the project. either the whole thing is transfered sold to a prospective enterprenuer or transfered to other( Manufacturing departmentor Plant)department of the same organisation.
The total purchasing process ideally should have JIT for more profitablity, how ever because of variuos reasons the process adopts and uses deferent methods.\
Regards
Krishna
SAP PS IM PM PLM consultant
Change in the development life-cycle is going to happen. Any Project Manager with actual experience knows that what a project team thinks they know at the beginning of a project is quite different from what they really know at different stages of the methodology. Defining what Change is, and how it is managed is the key. Are additional requirements simply being added (scope creep) or are requirements being clarified as the project moves forward.
The “fog of war” tells any experienced PM that what he thinks he knows at the beginning of a project needs to change. If he/she is inexperienced they will attempt to hang on to obsolete and inflexible requirements that don’t serve the business.