- Requirements definition. The requirements should not only be concise and unambiguous, they should also be testable.
- Requirements classification. To manage project development effectively, each requirement statement must be classified appropriately for the application to aid in effective decision making and resource allocation.
- Requirements traceability. Stakeholders of a project must be able to track requirements through the stages of development .
Requirements Management Blog
VijaySankar 270000E5JQ Tags:  requirements_management traceability refresher requirements 4,510 Views
Does the above graph ring a bell?
Many articles, papers and books have talked about the impact of fixing a defect at later stages of development life cycle. Researches have also been proved that majority of the software defects found in a project are related to requirements and continues to be higher than that arising due to design or coding issues. According to studies conducted, approximately 60%-70% of IT project failures result from poor requirements gathering, analysis, and management*. The most successful products and applications have been built with a thorough understanding of what they are intended for. Understanding and managing requirements are by far the most important aspect in the development life cycle irrespective of which technology, development process, industry or purpose of the software or system under development. The beauty of an effective requirements management is that it provides complete insights into how the development of a system is progressing for every stakeholder in the team yet at a level of abstraction neutral to technology, platform or perspective. It thus becomes the corner stone of software or systems development!
In today’s world, developing smarter products at the lowest time to market has become a norm for success. Often the level of pressure that mounts to get started and come up with a prototype or the product itself is high and requirements are cornered with least importance. But if we check statistics, we can see many examples that have caused hefty prices and disasters due to hasty development or lack of thrust given to understand the real requirements. Read a compilation by Computer World UK here. These two videos from IBM and IAG Consulting respectively talks about why you should consider requirements seriously.
If you watched the above videos, it is clear that the process of how requirements, are managed and collaboration and communication between stakeholders are equally important for an effective requirements management. Also many mistakenly believe that requirements management is something that takes place during the definition stages of a project and is then complete. However the reality is that requirements exist in some form at virtually every stage of development.
The three main factors to be considered while defining the requirements management are
Stay tuned for more posts on requirements management, analysis and other topics...
Have some suggestions/opinions/comments/topics...send us!
* Source: The Meta Group market research firm, a division of Gartner, March 2003
VijaySankar 270000E5JQ Tags:  ibm clm requirements_management doors rational rrc agile innovate requisitepro alm requirements 5,301 Views
In the last post we focused on what you can expect from Requirements Management for Systems Engineering track at Innovate 2012. In this post we will explore what is there in Requirements definition and management for IT application development track at Innovate 2012.
We have 16 sessions lined up in this track with focusing on software delivery that revolve around eliciting, defining, elaborating, understanding, organizing, reviewing, communicating and tracking business, user, and software requirements. We have multiple customer sessions; however I am sure you will find the below sessions interesting
Like previous editions of Innovate, this year also we have keynotes where IBM shares its road map, strategies and vision for requirements definition and management tools. Also there will be immense number of opportunities to meet senior product management professionals and developers of IBM Rational's Requirements Management tools in sessions like 'Ask the Experts: IBM Rational Requirements Composer and IBM Rational RequisitePro', What's New with IBM® Rational® Requirements Composer? and other presentations.
Some of the other notable presentations focus on trending topics and best practices in the requirements management domain like conceptual frameworks for visual definition in requirements life cycle, Requirements Engineering Maturity Model (REMM) and many more. There are multiple workshops about defining and managing requirements with IBM Rational tools, IBM Collaborative Lifecycle Management, best practices in using Requirements Composer and Jazz primers. Don't forget to try out Open Labs and solutions peds at Innovate!
And finally we have a competition (Who Is the Best IBM Rational Composer User? ) in which Rational Requirements Composer experts put their skills to the test to compete in a variety of different tool challenges and prove who is the best requirements tool champion.In this special event, participants have a chance to compete with IBM experts and tool developers to prove their expertise by solving common and difficult requirements management problems!
Have you registered for Innovate 2012? Hurry Up!!! just 9 days left...http://www.ibm.com/innovate/
Don't miss this opportunity to meet 4000+ professionals, attend your preferred sessions from 27 tracks and 400+ presentations and try out next generation products.
See you at Innovate!
VijaySankar 270000E5JQ Tags:  guest traceability ibm clm collaboration requirements-management requirements_management analysis requirements-engineering agile rational-doors doors requirements-traceability interview requirements communication rational innovate2013 requirements-analysis alm business-analysis ibm-champion 8,357 Views
Today we have with us Mia McCroskey at Emerging Health Montefiore Information Technology who was recognized as IBM Champion this year. She shares with us her thoughts about the requirements management domain.
Welcome to IBM family! It¹s a great pleasure to have you with us as an IBM Champion. Congratulations, How do you feel?
I am honored to be recognized in this way not just this year but for the past several years that I have been asked to present my team's stories at Innovate. It may seem like our little team's requirements management needs are nothing like those of customers with huge DOORS ecosystems. But really we are an R&D site for the evolution of requirements management techniques and strategies. If a member of my team has an interesting idea for how to capture, structure, track, or trace requirements, we can try it without getting high level approvals or disrupting the work of hundreds of people. I take tremendous satisfaction from sharing our successes in a way that may help others improve their best practices.
Can you tell us something about what you do at Emerging Health, Montefiore Information Technology?
Emerging Health is primarily an IT delivery organization supporting healthcare delivery in the Bronx. Montefiore Medical Center is our parent company. My team, Product Development, is a software development shop tucked away in a corner doing very different work from most everyone else. Our application, Clinical Looking Glass, is a browser-based clinical intelligence tool that gives clinicians access to the enormous wealth of patient data gathered by all the other systems. Our end users can get an answer to a question like "are my clinic's diabetic patients getting the level of follow-up care required by our funding sources?" in a few minutes. In most healthcare environments, getting the data that you need to answer this question takes weeks.
My title is Manager, Product Development Lifecycle because I have my fingers on just about every stage of that lifecycle. Specifically, I lead our Requirements Management, Quality Assurance, Education, Support, and Implementation teams. I also manage outsourced development work, manage client relationships, and do hands on end-user training and support. We are an extremely team-oriented organization, with two formal development scrum teams and two teams that are at various stages of adopting an agile process. I'm deeply involved in that right now: it's challenging to apply Scrum to a training and support team, and to a team of data analysts and engineers.
Having said all that, my roots are in requirements. On a team of "happy path" stakeholders who get very excited by ideas for new functionality, I love to dig in and find the challenges that nobody wants to think about -- before we start coding. Sometimes I feel like a real buzz kill!
What are your thoughts on managing requirements effectively?
Agile models have forced us to completely reorganize our requirements elicitation, analysis, and management processes. But one thing that has not changed is my belief in a comprehensive, functionally organized requirements model.
But when I say "comprehensive," I don't mean laboriously detailed. The art of requirements analysis and management is in knowing -- or guessing right -- what details are going to be important later. By later I don't mean to the coders and testers in this iteration, I mean when we want to revise or augment the feature in six months. The requirements analyst has to be deeply plugged in to the business goals and vision in order to predict the future and capture the least amount, but most important information about what the team is doing.
A few years ago I spent many months constructing an "as built" specification for a market data system at the New York Stock Exchange. I had the original ten-year-old spec and a few dozen incremental release documents. We were getting ready to refactor the system and nobody knew every business rule and function. I vowed that no system I worked on would ever lack a spec that described everything it currently did. Incremental requirements specs that aren't integrated into the overall system are defects waiting to be discovered once the coders get ahold of them.
Having argued that I must add that a requirements model in document form is pretty nearly impossible to maintain in the way I describe. You've got to employ a database tool that supports the granularity of each requirement and allows you to describe each one through attributes. Then you can use filters and queries and views to present an infinite number of customized specifications -- all of the requirements implemented in a specific release, or all of the requirements related to a specific functional area, or the completed requirements related to a specific business objective or corporate mandate.
I recently spoke with a software development professional who was very proud of his organization's highly structured and detailed requirements templates that captured every detail before any work began "to be sure we deliver what's wanted." I felt like I was talking to tyrannosaurus rex. We all know that the day after you baseline that 400-page spec it's already out of date.
Agile with its short increments and "only write down what you really need to" mentality can seem seductively freeing. When our organization adopted Scrum, I stuck to my requirements model guns, and sure enough a few months later we couldn't remember decisions that we'd made a few sprints back, nor even exactly which sprint we'd done the work in. Since we weren't supposed to be doing "heavy" requirements, we'd been coached to: use the system and see what happens; or sift through dozens of completed user stories and hope the detail we wanted was actually mentioned in the acceptance criteria (which it was not because it was an in-sprint decision); or try to find relevant test cases and check the expected results. Instead, I launched DOORS, went to the functional area related to the question, and checked our documented business rule. Done.
What are some of the challenges you see in Healthcare Informatics projects?
Deriving meaningful information from the electronic medical record is essential to justifying the cost of those systems. We're piloting the use of predictive analytics -- combining statistical methods with the mass of patient data collected every day at our parent medical center -- to predict outcomes at the population level. To do it you need a very wide range of data: blood pressure, height, and weight, smoking patterns, history of heart disease, current blood sugar level, and on and on. Just bringing all this data together is the first challenge. Next is the analytic tool -- that's CLG. Finally you need big iron to process it. Most local and regional healthcare providers don't have the funding for, say, Watson. My team spent last summer optimizing our hardware and software environment, and CLG itself, to handle analysis of larger data sets faster, but within a medical-center friendly infrastructure budget.
Another area of critical concern is patient information. The need to pool patient data for direct care as well as population research is supported by legislature and funding sources. But we are bound, both legally and ethically, to protect patient identity in every circumstance.
Clinical Looking Glass has the capacity to show patient contact information to users who have been granted permission to see it -- usually clinicians who are actively providing care and need to contact the patients. While this is a critical feature of CLG, we expect to have to develop more granular levels of access as new types of clients adopt the product. For example, our Regional Health Information Organization (RHIO) client has data from twenty-two healthcare institutions. Some patients have declined to have their identity shared across the organization. We have to build the capability to mask these patients' identity even to our users who have permission to see it.
Coyne 120000KAYY Tags:  requirements rational requirements-management jazz requirements_management ibmalm jazz.net clm 15,237 Views
Requirements come in a variety of forms and level of details. Well defined and thought out requirements have demonstrated time and time again to reduce development time, increase quality and lower the cost of a software project. Projects that lack specific requirements quickly fall into many of the typical traps of project failure.
In this era of agile, mobile and ever faster-paced world of today, some teams question whether managing requirements are still relevant today. Well I say teams still need to know what they are supposed to do. The developer may have ideas but in order to deliver something useful there must be a consensus on functionality and needs. And they need more than just a general idea scribbled on a sticky note, but specifically exactly what does the business and customer expect. Developers should not be expected to fill in the gaps with assumptions. Clear definitions of requirements actually accelerate the development process by reducing uncertainty and wasteful work.
Another point of view argues that requirements only have to be defined once at the start of a project , and not worry about them again during development. Sure you could consider that approach but then we quickly realize that change is all around us. There is no way we can ever realistically say the requirements are "done". Requirements are continually evolving even as development is underway and therefore the team needs to stay attuned and make adjustments along the way. Otherwise the risk is that the end result although matching up to the original requests, fails to meet the business need upon delivery. The only way to address this effectively is to realize that requirements are an intricate part of the lifecycle that continually evolve with the business and that the delivery team needs to be in sync to deliver these expected results.
To ensure requirements are written for the entire lifecycle it is important to realize that business needs come in many different forms, formats and language. Bringing them all together in a single place, removing redundancy, and connecting interrelated content is the first step to requirements definition and management. Capturing your stakeholder and user requirements is only the first step in realizing your project. As your project progresses and evolves, these initial requirements give rise to other requirements which elaborate, satisfy, and verify them. The result is a web of interdependent artifacts and relationships which represent the nature of the dependencies between these artifacts. Navigating and understanding this web of information is critical to the success of your project. Each stakeholder in a project may be interested in different information (e.g. defect backlog, current tasks, or release schedule). What helps here is a customizable dashboard displaying all the information stakeholders, developers and testers need at any time. As a new project is started and progresses forward many of requirements you define and capture will change, be added to, or sometimes removed through the course of development. You need the capability to track requirements information changes so that you can understand what has taken place throughout that process.
To learn about automated solutions for managing requirements, I recommend listening to this informative webcast Three Reasons to Throw Away your Requirements Documents
In summary I want to remind business analysts and the rest of the software delivery teams, that in this fast-paced delivery environment today, requirements are more important than ever. They provide the roadmap of exactly what is expected of the team by the business and customers. Everyone on the team needs to appreciate that requirements are never final and that they naturally evolve with the market and business. Teams that can capture evolving requirements and implement them in a rapid and iterative fashion will find a competitive edge in the market. Automating requirements provides the additional key benefit of traceability and collaboration to identify gaps and the impact of changes while facilitating the engagement of experts on the team to improve the quality of results.