Modified on by VijaySankar
We had a fantastic DOORS customer webcast panel on September 26 with experts from across the industries talking about their experience in using IBM Rational DOORS for requirements management. If we have to take one success metric for the webcast; it was that we overshoot by half an hour from the designated one hour for the discussion because we had some wonderful discussions going on. Our panelists have graciously agreed to respond to the questions on an offline basis, and we are publishing the answers here.
If you missed this golden opportunity and is wondering whether you can get another chance? YES! Or you would like to listen to it again; we have posted the replay here. You can listen to it anytime now. Register here
How to copy the objects with in-links and out-links from one module to another module?
< >Use DXL scripts that capture link information, which can be edited if necessary, and then copy the objects, and then run another dxl script to re-create the links.
Paul Lusardi has shared with us couple of samples. If you are interested, contact us
What factors determine using new database vs a new project in a database to differentiate/segregate work?
< >The biggest criteria for using the same database is Linking. If there are Projects in a database that you need to link to, the new Project should be in that same DB.The default should be to use the same database so that you only have to maintain one set of users, groups, standards, etc…. the possible exception is if you have 2 distinct sets of security measures (HIPAA, DoD or DoE cleared data) then you will want to segregate that out to a different server.
Does anyone on Panel publish documents directly from DOORS without Add-on applications?
< >[Patrick] I use DXL scripts which export the data out to RTF with some typical publishing formatting
[Mia] < >I do. Whether you can depends on the demand for documents (do you need to do them once a week? Daily? Quarterly?) and how critical their formatting is to your organization. We have configured views in most modules for output. A simple one has just the object number and the Object Heading/Object Text. For a full spec, we include trace columns for one or more linked modules, with object identifiers and even object headers or text in those columns. In the output you get the main object from the current module, followed by all the objects it’s linked to. I keep in a label that specifies “in link” or “out link.”I used to painstakingly populate the Paragraph Style attribute in order to map to MS Word, but because our need for documents is very low I have stopped enforcing this. We have a set of MS Word templates with the title page, toc, other front matter, and a standard set of styles. Plain Vanilla DOORS maps to basic Word styles fairly well.I pick the appropriate view and filters and select Export to Word. I select the appropriate Word template, and let it rip. I then do some minimal post processing, like getting rid of the object IDs on headings. Obviously if you’re doing very long documents this would be impractical.In my previous job we had interns create a DXL script that handled the post processing – you can get to something that’s usable without a huge investment.
How do you deal with sharing of your database with the government or other contractors? Do you share read-only partitions ?
[Paul] < >Previous to coming to NuScale, I co-developed the Unified RM Database where we allowed outside access, using access control and company VPN login credentials to enable multi-company development and reviewer teams to look at the data.The questions would be …..do you want them to see work in progress? Or just a snapshot of baselined work? Perhaps a separate server with a restored baseline set would be best in that case. I will defer to an expert on baseline sets though
How do you get rid of allowing DOORS Links?
[Patrick] We use a link schema with Pairings as necessary, and then create and delete but not purge the DOORS Links module with a copy in every sub-Project/Folder, and leave it as the default Link Module. That way, users cannot create a link that is not intended between any module pair.
Paul Lusardi has shared us a presentation. If you are interested, contact us
Is there a "Copy View" script available?
Paul Lusardi has shared us a presentation. If you are interested, contact us
Please ask about doing risk assessment in DOORS: Do any of the panelists document FMEA or risk analysis in DOORS? How do they do it?
< >[Paul] Yes and no. Textbook FMEA? No. using DOORS to analyze potential risks by means of looking at risk informed design? Yes, this is a “developing” activity[Patrick] We capture the risk status in DOORS, but not the actual assessment data
Do any of the panelists integrate DOORS with other tools like Rational Quality Manager?
< >[Patrick] We are looking into it, but have not actually started using in Production. Going to deploy DOORS/CQ by year end.[Paul] Only RPE integrations are used here
How has your work differed because you use SCRUM vs. when you did not?
Our pre-sprint requirements work is at a higher level – that is, not down in the functional weeds. We spend more time exploring new features from the user’s perspective, and more time on storyboarding and similar activities. The features we’ve built since going to agile are much more user-friendly and have much better workflows than the older stuff, where much of the workflow and usability decisions were left to the engineers.
Detailed functional analysis of requirements happens during the sprint, with the requirements analyst on the team working closely with the engineers and testers. For very complex features, this analysis process will begin before the sprint so that we have enough functional detail for the team to estimate the work. We have a small backlog grooming team that, members of the scrum teams, who help the requirements analyst with this.
For Mia, for your agile, how many full-time admins needed to maintain DOORS?
[Mia] We’re very small, so we don’t even have one full time admin. Our system engineer handles the environment, and I handle user administration. It’s a tiny part of each of our jobs. I don’t see that our approach represents a particularly different administrative need than any other. If we had a hundred users and multiple DOORS databases, then we’d dedicated administrative resources just like any other implementation.
@Mia - Are requirements for HW to SW interfaces traced through ICD(s) in DOORS?
We’re software only, so no HW/SW interfaces. However, I strongly support the use of interface specifications between software systems and have used an interface module to sit in between systems that need to interact. The trick is to stay on the requirements side of the requirements/design line. The cost of maintenance on such a model is high – probably too heavy for our agile process to maintain. However, should we need to support integration with an external application (one that our teams are not developing), our API requirements will undergo close scrutiny and possibly be carved out into a separate module so that we can use trace links to do impact analysis on external “clients.”
Do you DOORS lend itself to any specific Devops , ALM methodology liek Agile etc?
We adopted a continuous deployment model this year and it had no impact on our use of DOORS. That is, DOORS is still a critical part of our development tooling. We were already capturing release version information for requirements in DOORS, and this information remains very useful in understanding what feature set exists in a given version of our application.
Try IBM Rational DOORS in a Sandbox
Webcast - Achieving sustainable requirements across the supply chain with IBM Rational DOORS
A leading analyst and Systems Engineering expert, David Norfolk of Bloor Research recently published a white paper titled Reducing the risk of development failure with cost-effective capture and management of requirements. In this report, David dwells into the relevance of requirements management as a discipline and put forth his views on how the domain is changing with the advent of new development paradigms such as agile, mobile and devops.
If enterprise architecture helps to bridge the gap between business strategy and vision and its implementation in technology, from the CEO’s point of view, Requirements Management continues to help bridge the gap between business and technology at a lower level.
The report provides valuable insights with his deep coverage about why requirements management is relevant even more today, issues associated with managing requirements, challenges faced by the discipline, best practices from his experience and his thoughts on the capabilities of an ideal requirements engineering tool. Some of the topics the whitepaper discusses about are --
Challenges in requirements management
Managing changing requirements
Scope and ideal capabilities of a requirements engineering tool
Real life examples of benefits from investing in requirements
Read the whitepaper here - Reducing the risk of development failure with cost-effective capture and management of requirements
Modified on by VijaySankar
This year, Innovate - The IBM Technical Summit will be held from June 2 to 6 at Orlando, Florida. As in previous editions, we will be having two tracks dedicated to requirements management at the event. One track would be focusing on requirements definition and management for IT/Application development and the other track will be focusing on Requirements Engineering for Systems and Product development. Each track will have 16 sessions starting with the individual track kickoffs. This year the conference will witness personalities like Steve Wozniak, Eric Ries and many other.
The requirements management track will showcase more than 25 real life case studies and best practices from across the industries ranging from Banking to Insurance to Aerospace & Defense to Energy & Utilities. Some of the interesting sessions to watch out for are
Agile Requirements: Maintaining the Model Through Iterations (by Mia McCroskey, IBM Champion at Emerging Healthcare IT)
DOORS Next Generation: 1st Impressions and Key Comparisons (to IBM Rational DOORS) [by Alex Ivanov, IBM Champion at Raytheon]
Successful RRC adoption through a Community of Practice: Case Study from Blue Cross Blue Shield of North Carolina
Cerner Corporation: Migrating from Requisite Pro to RRC
Piloting Rational Requirements Composer for Enterprise-wide deployment: The Good, the Bad, and the Ugly (Fidelity)
Managing Parallel Streams of Requirements in DOORS at an Automotive OEM
A DOORS-based solution for semi-automated risk analysis within MedTech
We also have two instructor led workshops for Rational DOORS and Rational Requirements Composer. Learn more here. Demo booths, self paced tutorial labs for DOORS, DOORS Next Generation and RRC are also organized during the event.
Few other attractions for anyone interested in the field of requirements management are panel discussion, Meet the developer sessions, sessions from organizations like IAG Consulting, IIBA and INCHRON.
Every year Innovate attracts 4000+ professionals from across the world. Join us for one of the biggest technical conferences to learn, meet and network with like minded technical professionals. For more details about the conference visit Innovate 2013 - The IBM Technical Summit
Here is the detailed agenda of requirements management topics at Innovate -
ps: agenda subject to change
Modified on by VijaySankar
Jeremy Dick works as Principal Analyst for Integrate Systems Engineering Ltd in a consultancy, research and thought leadership capacity. He has extensive experience in implementing practical requirements processes in significant organizations, including tool customization, training and mentoring. At Integrate, he has been developing the concept of Evidence-based Development, an extension of his previous work on “rich traceability”. Prior to this appointment, he worked for 9 years in Telelogic (now part of IBM Rational) in the UK Professional Services group as both an international ambassador for Telelogic in the field of requirements management, and a high-level consultant for Telelogic customers wishing to implement requirements management processes. During this time, he developed considerable expertise in customizing DOORS using DXL to support advanced engineering processes. His roles in Telelogic included a position in the DOORS product division to assist in the transfer of field knowledge to the product team. Co-author of a book entitled “Requirements Engineering” that has recently reached its 3rd edition, he is recognized internationally for his work on traceability.Jeremy can be reached out at jeremy.dick[at]integrate.biz
It is a bit of a shock to find myself well into the fourth year on the same project! The nature of my work as a consultant means that it is rare for me to stick with a project beyond the initial phases of defining a requirements management process, establishing effective tool support and training the process enactors. But this time we have been able to stick with the requirements team supporting a large project long enough to see theory put into practice, and to see what it really means to apply the tools and techniques. We have gone well beyond just training, and find ourselves mentoring nearly 300 engineers in the application of DOORS for requirements capture, development and management. This has helped us keep our feet firmly on the ground – rubber on the road – and to walk with those who actually have to do the work.
So what have we learnt?
It is one thing to teach people how to write requirements statements that are clear, unambiguous, testable and traceable; it is quite another thing to help people understand how to take a requirement and develop it. None of the engineers we met on the project had previous experience of how to take a system requirement, for instance, and systematically decompose it through the design into sub-system and component requirements. We had to adapt our training and mentoring to address this skill.
Requirements decomposition establishes one of the essential requirements traceability relationships: how each layer of requirements contributes to the satisfaction of the layer above. This is often known as the satisfaction relationship, or as refinement in SysML. It is this relationship that connects the design to the development of requirements, and that lies at the heart of the ability to perform impact analysis.
Whatever layer you are engaged in – customer, system, sub-system or component – the same basic requirements development process can be applied. These are the process steps we teach for requirements development:
1. Collect and agree your requirements.
Here you actively seek out the requirements you are expected to fulfil. In an ideal world, development will be perfectly top-down, and you can wait for the layers above to allocate perfectly expressed requirements to you. In a practical world, you will have to be more proactive, and will have to cooperate with your requirement “customers” to obtain acceptably worded requirements.
2. Design against your requirements.
This stage is the creative bit that you perhaps most enjoy doing, and where the real engineering takes place. You will imagine how to design the system to meet the requirements, and what you need your requirement “suppliers” to do to contribute to your design. In other words, if you are at the system level, you design the system into sub-systems, and work out what each sub-system must do to meet the system requirements.
3. Decompose the requirements to reflect the design.
Now you enter the decomposed requirements and trace them back to the requirements they satisfy, thus making the requirements contents and traceability reflect your design. The wording of the decomposed requirements is important: if the original requirement read “The <system> shall ...”, then it is likely that the decomposed requirements will read “The <sub-system> shall ...” At this stage you can also capture rationale for the decomposition, including references to the design documentation or models, thus tracing also to design information.
4. Allocate the decomposed requirements.
Finally, you can pass on the decomposed requirements to those areas responsible for fulfilling them. These other areas engage in the same process, and together you systematically achieve alignment of requirements through all the layers.
The example below illustrates the end result of applying this process on a user requirement decomposed into system requirements. The rounded box contains the design rationale, and refers to a functional model of the product. (If you’ll forgive the shameless plug, such diagrams can be produced using a DOORS extension related to TraceLine. Ask me more if you are interested.)
The example just shown is a classic decomposition pattern. It is actually the decomposition of an overall performance into a combination of capacity and performance attributes of the product. We call this “decomposed”.
Other decomposition patterns are possible. Sometimes no decomposition is necessary, because the system requirement can be satisfied entirely by a single component or sub-system, as in the left-hand example below; or a constraint that will apply universally to all parts, as in the right-hand example. All that changes, perhaps, is the wording of the requirement to indicate the new target. We call this “direct flow”.
You will reach a point in the cascade of decomposed requirements when a requirement is satisfied entirely within the current area without the need to decompose further, as illustrated in the following. In this case, it is important to state the rationale for not flowing the requirement onwards, as otherwise it may be construed as a traceability gap. We call this “not developed further”.
I have seen a number of organisations that capture this flow-down type – Decomposed/Direct Flow/Not developed further – as an attribute of the requirement. We do this because it allows us to cross-check certain things: if you have marked a requirement as “Decomposed” but have not decomposed it, then that does indicate a design gap. However, if you mark the requirement as “Not developed further”, that gives you permission not to trace it further, i.e. not a design gap. (But you would do well to provide rationale!)
As requirements flow down through the layers, the complexity of the design becomes evident in the shape of the requirements graph. In general, satisfaction is a many-to-may relationship between requirements, and the figure below shows how this may be manifest. As the requirements are decomposed, they are refactored through the design.
Some patterns are questionable. Take these for instance:
Why decompose something into three requirements only to reduce them to a single one again? Or why collapse three requirements into one only to re-expand them in the next layer?
These patterns are not necessarily wrong, but they should be targeted for careful review.
So this is what we now teach those engaged in requirements decomposition, flow-down and traceability. It is wrong to assume that people will somehow automatically know how to do this kind of thing. By taking this approach, the flow-down of requirements reflects the design, and a clear satisfaction relationship is expressed in the traceability.
Read the second part here - The practical application of traceability Part 2: What’s really going on when you plan V&V against a requirement?
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.
Modified on by VijaySankar
Just like the famous (mis)quote of Mark Twain, rumors of the demise of the requirements management tool IBM Rational DOORS are not only exaggerations but in fact untrue. I’d like to put straight here some of the myths and misunderstanding that I’ve heard and seen perpetuated:
Myth: IBM is discontinuing support and development for the DOORS 9.x series
Truth: IBM continues to develop the DOORS 9.x series with the same level of development resources. We have new functionality to announce in 2013 and plan further releases in the years ahead. In addition IBM has recently invested additional development resources in creating a new Requirements Management tool called IBM Rational DOORS Next Generation (DOORS NG).
Myth: IBM is replacing the DOORS 9.x series with DOORS Next Generation (DOORS NG) and expects customers to migrate now
Truth: DOORS 9.x will be developed in parallel with DOORS NG for many years to come. DOORS NG was released for the first time in November 2012. The tool has many functions DOORS 9.5 does not have, e.g. fully functional web client, type and data re-use (requirements & attributes), team collaboration, task management, but also does not have all of the capabilities relied on by DOORS 9.x users. We encourage users to evaluate the capabilities of DOORS NG and start projects or move projects to DOORS NG when practical and beneficial to the project.
Myth: To move to DOORS Next Generation, I’ll need to buy a whole new tool
Truth: Customers with active support & subscription on their DOORS 9.x licenses are entitled to use DOORS Next Generation - it is included as part of the DOORS 9.x package. Customers can choose to use either DOORS 9.x, DOORS Next Generation or a combination of both. There is no need for additional purchases or even for an exchange of licenses. All licenses are available to customers in the IBM license key center.
Myth: IBM offer no migration path from DOORS 9.x to DOORS NG
Truth: IBM do offer functions to transition into using DOORS NG for existing DOORS 9.x customers:
Work with DOORS 9.x and DOORS NG alongside each other - both tools support linking of information between both databases.
Work with suppliers by exchanging requirements through the standard exchange format of ReqIF. This works best between DOORS 9.x and DOORS NG but is also designed to work with other RM tools.
Where DOORS NG projects wish to be initialized with data from DOORS 9.x we offer re-factoring functions to harmonize the transition of data from DOORS 9.x to DOORS NG.
Myth: Everyone knows IBM’s strategy on requirements management and DOORS
Truth: IBM takes great care to regularly communicate our product strategy and roadmap at trade shows, IBM conferences and on webcasts. If in doubt, come and ask IBM! Please submit questions using the comment feature here or contact your IBM representative.
For information about the products, visit -
IBM Rational DOORS
IBM Rational DOORS Next Generation
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.
What are your thoughts on the role of requirements management in agile projects?
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.
On Thursday 14 March I presented on an IBM sponsored Dr Dobbs webcast on the topic of ‘3 Reasons to Throw Away Your Requirements Documents’. If you didn’t catch the webcast, you can view it on-demand and download the slides. If you did attend I hope you enjoyed it and in this blog post I want to answer some of the questions that I didn't get time to cover in the webcast, so scroll down to see if I've covered your question here. But first, for those of you who didn't make it, here's a quick recap of points I made during the webcast:
- What do I mean by ‘Throw Away Your Requirements Documents’? I’m not saying do away with your requirements or your requirements management process. What am I saying is invest in improving your requirements management process and support those process improvements with the right tooling. In the webcast audience poll, 60% said they are using documents and/or spreadsheets for requirements, so I set out to provide the case for why they should consider moving to a requirements management tool.
- Reason #1 – Collaboration. Using documents and spreadsheets, you can get into all sorts of problems like working from the wrong version of requirements. An integrated requirements management tool (one that has a collaborative repository that has open interfaces to share requirements data with design, test and development environments) helps you ensure that all engineering / development team members and their stakeholders are working from the right version and view of requirements for their role. I shared information from a case study on MBDA Missile Systems where collaboration was a major challenge.
- Reason #2 – Traceability. Traceability helps you get context and an audit trail for decisions made, perform coverage analysis, detect gold plating and perform impact analysis (See blog posts ‘What is Traceability?’ and ‘The uses and value of traceability’ for more explanation). But using documents and spreadsheets to create and manage traceability gives it a bad name – it becomes a tedious, error-prone overhead activity. With an integrated requirements management tool traceability links can be easily created and navigated. Traceability becomes part of the process rather than a bulk catch-up exercise, and through open interfaces it becomes easy to extend traceability from requirements to artifacts in other tools such as designs, work items and test cases. And most importantly there are automated views and reports that enable you to make active use of traceability for the purposes I mentioned above. I shared information from a case study on Invensys Rail Dimetronic where traceability is essential.
- Reason #3 – Agility. As many engineering and development organizations are looking to improve time to market and reduce costs, agile approaches are becoming increasingly popular (in the webcast audience poll 56% said they were using some sort of hybrid waterfall/iterative approach and 20% were agile), and with that comes changes to the way requirements might have been traditionally defined and most importantly to the way that changes to requirements are managed. Change is allowed and encouraged but you must have reviews and impact analysis to make informed decisions about whether to accept the change and implement in the current iteration or sprint, plan it into a future iteration or reject the change altogether. And to do that requires more than just a backlog managed in a spreadsheet or an agile planning tool. At IBM Rational we keep a prioritized backlog of user stories and epics as work items in plans managed in Rational Team Concert. User stories and epics are then decomposed and more fully described by requirements and supporting visual and textual artifacts created and managed in Rational DOORS Next Generation.
- And I started and concluded by looking at the most compelling reason for improving your requirements management process with the support of the right tooling: Return on Investment. I shared information from a case study on Emerging Health, Montefiore IT where they a achieved, among other benefits, a 69% reduction in the cost of quality (test preparation, testing and rework) within 6 months of deploying an improved requirements management process supported by IBM Rational DOORS. There’s also a follow-up video to this case study that was recorded after the client had adopted agile development practices.
Ok now onto some of the questions that were submitted but I didn’t time to answer during the webcast. I’ve divided them into sections based on the type of question so you can easily scan down to topics you’re interested in:
Alternative approaches to managing requirements
Q. What's the advantage of a requirements management tool if I could link my change management tickets to fine grained requirements (use cases, storyboards) that are maintained on a wiki or other collaboration tool (e.g. Sharepoint or IBM Connections)? It would seem that the work items would give you the needed traceability and metrics?
A. While you might be able to create the level of traceability you require, how would you report on it? Would you have to build bespoke views and reports? And would the use of a wiki for ‘fine grained requirements’ provide you with a view of requirements in context with one another as opposed to individual wiki pages? Where would you document additional properties of requirements? Could you easily reuse requirements across projects? A requirements management tool like IBM Rational DOORS Next Generation provides built-in traceability views and reports, enables to you to structure requirements in context with another in document-like views, provides user-defined properties for recording additional information and facilitates reuse of requirements.
Requirements Management and Agile Development
Q. We are mostly using water fall model, but looking into checking if Agile works for our customers. I am very interested in the role of a Requirements Analyst in the Agile world. In our world, the analyst is a facilitator of requirements gathering and not a SME on the business application we are gathering requirements for.
A. That facilitation role and the analysis skills of the Requirements or Business Analyst are still essential in Agile development. A common mistake when moving to moving to more agile approaches is appointing a ‘Product Owner’, who is a subject matter expert in the business domain you are building an application or product for, and expecting them to write the requirements or ‘user stories’. While they are experts in the business and you need that expertise on hand for Agile to work, they are not usually skilled in getting to the root goals or needs of the business problems you’re looking to address with the product or application. Without the skills of the Requirements or Business Analyst, it’s all too easy for the user stories to become about automating the way things are done today rather than addressing the real business issues in an optimal way. You can read more about the role of the analyst in Agile development in an interview with Mary Gorman of EBG Consulting.
Q. How does the IBM requirements toolset compare to more "agile" focused toolsets like Atlassian, Rally, etc.?
A. IBM is very committed to supporting agile development, particularly when agile is scaled to large, distributed development teams. At the heart of our agile development capabilities is Rational Team Concert which supports agile planning, task management and change management. As stated in the webcast though, we’ve found in our own continuous delivery process and heard from clients, that a place is needed to capture more details of requirements and their associated properties, in context with one another, together with supporting artifacts like storyboards, workflow scenarios and use cases. The integration of Rational Team Concert with Rational DOORS Next Generation provides those additional capabilities while preserving traceability to user stories and epics managed in the product backlog.
IBM Requirements Management solutions
Q. It seems this discussion is on Rational DOORS. Is Rational Requisite Pro still offered? If so then how do these two products compare?
A. IBM continues to support, maintain and respond to enhancement requests for Requisite Pro, but our future direction for requirements management for IT application development lies with Rational Requirements Composer and we provide migration support and a trade-up program. Please contact your IBM representative for more details. If you are using Requisite Pro for requirements management for complex products or embedded systems development, then you might also want to look at whether Rational DOORS or Rational DOORS Next Generation is the right move forward for your organization. But don’t worry we’re not forcing you to migrate today.
Q. You've mentioned DOORS Next Generation in your presentation, what is that? Does it replace DOORS?
A. IBM Rational DOORS Next Generation is a requirements management application on a collaborative lifecycle management platform for systems and software engineering that provides requirements collaboration, planning, reuse and lifecycle traceability. DOORS Next Generation (DOORS NG) was introduced in 2012 to take advantage of the common, collaborative ‘Jazz’ platform shared by Rational Team Concert, Rational Quality Manager, Rational Design Manager and Rational Requirements Composer; and to extend the requirements management capabilities in Requirements Composer to meet the needs of product & systems development organizations developing complex and/or embedded systems. DOORS NG will enable IBM to introduce new capabilities, faster, that would have been more difficult to deliver with existing DOORS product. However DOORS NG does not replace DOORS today. We have a very large install base of DOORS users working on programs that can last tens of years, and we will continue to support, maintain and enhance the DOORS 9.x series to meet the needs of those users. We encourage existing DOORS users to take a look at DOORS NG, to try it out on pilot projects and use the interoperability capabilities to exchange and/or link data with DOORS 9.x. Existing DOORS customers with active support & subscription are entitled to use DOORS NG without requiring an additional purchase – you can use your existing DOORS license entitlements to use with either DOORS or DOORS NG or a combination of the two. But we are not telling existing DOORS users to migrate live projects to DOORS NG today. DOORS NG in it’s early releases is attractive to organizations who don’t currently use a requirements management tool and are looking for a web based solution that also offers common platform integration with change management, agile planning, test management and design management capabilities. You can download a trial and follow development plans for DOORS NG on Jazz.net.
Q. How does Rational DOORS Next Generation compare to Rational Requirements Composer?
A. DOORS Next Generation is based on Rational Requirements Composer but extended to meet the requirements management needs of product & systems development organizations developing complex and/or embedded systems. In the first releases of DOORS NG, the web client is identical to Requirements Composer, but DOORS NG also features a rich client which is designed for usability of editing large requirements specifications. The strategy for the two products is that while Requirements Composer will be focused on the needs of business analysis and IT application development teams, DOORS NG will be focused on the needs of systems engineers and product & systems development teams.
I’d like to wrap up this post by thanking all of you who attended the webcast, participated in the polls, asked some great questions and completed the survey feedback. If you missed it, you can catch a replay or download the slides. I’d welcome any additional comments or questions here.
Today we have with us, Theresa Kratschmer writing about the importance of metrics in requirements management. Theresa Kratschmer is a senior software engineer who joined IBM T.J. Watson Research in 1996. There she worked on defect analysis, requirements, and Orthogonal Defect Classification deployment. In 2010, Theresa moved to sales where she is a technical specialist focusing on the Rational Jazz products. Previous to joining IBM, Theresa developed software for real-time, graphics, and database applications in the medical electronics industry. She can be reached out at theresak[at]us.ibm.com
Everybody is talking about metrics today. Numbers have always been important to builders, financial wizards, and politicians. If you were a software developer though, you may have taken a lot of math courses but you didn’t really use that math directly. So, why the sudden interest in software and metrics or specifically in requirements and metrics?
Metrics are important whenever you need accuracy such as building a house or sewing a dress. They are important when you need to work efficiently and you can’t afford waste. In today’s business environment, every organization out there, whether a finance company, government agency, or healthcare organization needs to work more effectively and produce more data, more projects, more software with far fewer resources. Numbers, or metrics, is the way to do this. Since requirements are the foundation of software, it is one of the best places to apply metrics. By applying measurements to metrics, we get insight into the organization’s requirements activities. We find out how much progress is being made, whether we have gaps in the downstream deliverable related to requirements and how big our project risk might be when changes occur to those requirements. Applying measurements to requirements also allows us to make continuous improvements.
So if metrics are so valuable, why aren’t more people collecting them? There are primarily three reasons
- It often takes too long to collect the metrics. By the time you end up gathering all the information you need, it’s out of date already.
- How do you interpret the information that you collect? Some people feel that if you don’t have access to a person with a PhD, you’ll never understand the numbers.
- Even if you collect the data and you correctly interpret it, is the organization actually going to do anything with that data to actually make improvements?
The best way to collect metrics, of course, is to do it automatically as the team goes through their daily activities. As they define and refine requirements, process requirement reviews, perform change management and quality management activities, data can be collected automatically, processed, and made available in real-time. This is exactly what an integrated solution like Jazz platform
does. It basically removes this obstacle and makes data collection, processing and display of data a natural part of the project team’s daily activity.
Interpretation of Data
Understanding data and resultant reports does take some skill. But it is not complicated. I always start by articulating exactly what information I want to view or what questions I need answered. Then I look for the data that will help me answer those questions. For example, you might want to which high priority requirements have no test cases associated with them. One of the capabilities with the Jazz suite that helps here is that the reports have a section called “What does this report tell me?”. When you run a report, you actually have some automatic interpretation built in. Of course, I always recommend people start simply. Your skills will grow as you get more comfortable understanding and interpreting the data. Jazz also allows you to set up filters which help you answer specific questions at the click of a button. This makes analysis automatic and very, very easy.
Improvement Actions for Continuous Improvement
Identifying and implementing actions is one of the most important aspects of ensuring continuous improvement. It’s very important when analyzing data that indicates weaknesses in your process to actually identify improvement actions. Not only do you need to identify how you will improve your project and processes you follow, but you also need to assign owners and a date for implementation to make sure you do actually make improvements.
I hope I’ve convinced you that metrics are important – well worth the time and effort it takes to collect and analyze data. By identifying and implementing improvement actions your organization can make considerable progress in working more efficiently and really achieving the ability to do more with less.
Anthony Kesterton is a Technical Consultant in the Financial Services Sector for IBM Rational in the United Kingdom. He has a wide experience in IT development including many years teaching, mentoring and using various IBM Rational tools, as both an end-user and as an IBM employee. He is a regular contributor on the forums on jazz.net. He is co-author of the IBM Redbook “Building SOA Solutions Using the Rational SDP”. As an IBM Community volunteer, he works on programmes dedicated to encouraging children to take an interest in Science, Technology, Engineering and Mathematics (STEM) at school. He also regularly writes in IBM Technical Field Professionals' blog here. Anthony can be reached out at akesterton[at]uk.ibm.com
One of the more interesting discussions I have had about requirements was how to indicate that a requirement must be implemented in the final system. The business wanted to make every requirement “mandatory” which gives no indication to anyone which requirements are really important. Eventually, the business analysts compromised and had levels of “mandatoriness” (I think I might have invented a new term) starting with “least mandatory” to “most mandatory”. The business was happy to accept this. To me, this showed the importance gaining agreement on the requirement attributes. It should not stop at attributes – attribute values, requirements types, traceability and document templates are also very important for a project. All this information should be part of a Requirements Management Plan.
A Requirements Management Plan has nothing to do with time and resources on the project but everything to do with structure of the requirements. A Requirements Management Plan is a way to capture the kind of requirements that will be used on the project, their attributes and other useful information. A typical Requirements Management Plan should contain the following:
- Types of requirements: For example, business requirements, system requirements, and performance requirements.
- Attributes: Important information associated with each requirement type, for example: priority, source of the requirement, or the stability of the requirement
- Attribute values and the meaning of these values: Each attribute should have a range of possible values, and these must be agreed upon and documented. For example, an attribute for priority may have a value from 1 to 5, where 1 means the highest priority and 5 means the lowest.
- Traceability between requirements: There is usually a hierarchy of requirement types. This hierarchy needs to be captured and explained. For example, a feature of the system may link to a software requirement, with the feature at the top of this hierarchy.
- Document templates: Many organizations have standard ways they present information in document form. They might have a Software Requirements Specification with a specific format and structure.
Having the discussion about this plan, and getting agreement on the content of the plan can be enlightening. It can uncover what kind of information is important to the project, how the project plans to manage the requirements (via the attributes), and most importantly, what kinds requirements where overlooked. While the plan is being discussed, be prepared for heated debates about potentially every aspect of the plan.
Spend time creating a Requirements Management Plan for your project as soon as possible. Be prepared for changes to that plan over time as the project works out the really useful attributes or even requirement types. Most importantly, get agreement on the Requirements Management Plan – it really does help a project build requirements that clarify rather than obscure the intention of a project.
Note: This is the sixth post in our series of Managing Your Requirements 101. Read the first five posts here:
- What is requirements management and why is it important?
- How to write good requirements and types of requirements
- Why baseline your requirements?
- What is traceability?
- The uses and value of traceability
Requirements elicitation is the process of discovering and clarifying the needs, capabilities, conditions, and constraints that a project must satisfy to deliver a solution or product that meets the client/market needs. Requirements elicitation is by far the significant activity taken by a business analyst or requirements engineer. Elicitation in a traditional world begins early in the cycle – consulting or development while determining the scope and objectives of the project. Generally it extends to the analysis and design phases. We will delve in detail how this differs in agile in a later post. In either case, elicitation is an iterative and ongoing process which takes care of clarifying, refining requirements and identifying constraints and new changes. The amount of elicitation of requirements depends on where you are with the engagement lifecycle. Elicitation happens at various levels - early on to draw down the initial requirements and later on to refine them to specifics.
So what are the sources of requirements? The main sources of requirements are the stakeholders themselves. The end users, SMEs in the domain are also prominent sources for clarifying requirements. Other sources could be the regulatory requirements, existing documents, past experience and business cases.
Essentially, the requirements elicitation starts with a method adoption workshop. A Method Adoption Workshop (MAW) helps in determining the key requirements activities, templates and outputs. The workshop essentially acts as a discussion venue to determine the optimal activities for the project. Various methods can be used for these workshops. Most of them prescribe how to collect and specify requirements and in some cases how to manage them also. Some of the most used methods are SE&A Method and Custom Development Method or proprietary ones like SAP. These workshops also help in putting in place effective project change management processes. Thus effective scope management is the combination of requirements management and change management. MAW is used to tailor and adopt the project management and technical methods for the product and determine the optimal activities needed. Post MAW, stakeholders are identified and various elicitation techniques are used for determining the requirements. Techniques can vary according to the group of stakeholders. A consolidated business requirements document is created for client review.
Understanding the project environment is the key to determining the requirements. This could act as the starting point of elicitation. INCOSE Systems Engineering Handbook provides a classification of various sources of requirements - External environment (like the regulations, laws, culture, and competition), Enterprise environment (internal policies, technology), Project environment (budget, tools, project management) and Support functions in the organization. Before looking into the various elicitation techniques, some of the factors to consider are - the triple constraint - cost, schedule and scope; stakeholder influence, stakeholder access and willingness to participate, contractual deliverables and organizational experience in similar projects.
Broadly we could categorize the elicitation techniques into Structured techniques, Analytical techniques and Interactive techniques. I believe the genesis of structured techniques is from marketers. Generally these techniques include interviews, focus group discussions, surveys and workshops. Analytical techniques could include interface analysis, domain experience, and market research. Interactive techniques could include brainstorming sessions, prototyping, observation and reverse engineering. Many text books have dealt in detail these techniques and when to use them; however Unearthing Business Requirements: Elicitation Tools and Techniques by Kathleen and Rosemary deals with this topic in detail. We will look into some of the techniques in detail in a later post and also touch base of when to use which techniques.
Some useful resources
Form feeds function: The role of storyboards in requirements elicitation
Requirements Elicitation Introduction, Nancy R. Mead, Software Engineering Institute
Modified on by VijaySankar
Note: This is the fifth post in our series of Managing Your Requirements 101. Read the first four posts here:
Part 4 of this series ‘What is Traceability’ looked at the definition of requirements traceability and different types of traceability relationships. In this part, let’s look at what traceability can be used for and where it delivers value to application, system or product development.
Why is traceability necessary/important? Isn’t traceability just an overhead, an onerous documentation task that’s only done in industries where it’s mandated? In my view it’s true that requirements traceability practices have originated from industries like aerospace & defense, where one use of traceability is to show that contractual requirements have been addressed, but it also has so much more value to bring when used effectively, and you have the right tools to maintain it and report on it. The following lists some of the ways that traceability delivers value:
Context: If you can trace back from a design or test to a user requirement, you then have the reason for the existence of that design or test and through the information in the user requirement (and through any related requirements you can trace to), you have more supporting context to help create the optimal design to meet the requirement or the most effective test to verify that the requirement is met
Audit trail & compliance: Taking an example of a new person joining a project, traceability can help them navigate the project and see why particular requirements, designs, tests, etc. exist. This is also of upmost value and importance when you need to demonstrate compliance to a regulation or standard to an auditor – the traceability trail can help you quickly show you are addressing the regulation or standard.
Coverage: How do you know whether you’ve covered all the user requirements in the derived systems requirements, designs, tests, etc.? Traceability can help you here – you can see gaps indicated by where a higher level artifact doesn’t have any relationships to lower level artifacts. Of course even if a relationship exists you still need to follow it and examine the lower level artifact to ensure it does what the traceability relationship says it should, but at least you had a signpost to direct you to the right place to look.
Gold plating: As well as highlighting coverage gaps, traceability can help you investigate possible ‘gold plating’ or over-engineering. If you have a lower level element without any relationships to a higher level then you can ask the question – why does this exist if it’s not apparently satisfying a requirement? There might be a perfectly valid reason but this gives the opportunity to identify and eliminate anything that could bring unnecessary additional time and cost to the project.
Impact analysis: I think this is the most valuable reason for traceability. If you have traceability relationships in place you can following those relationships when say a user requirement changes, to identify all the related system/sub-system/component requirements, design elements, tests, work items, etc. that are potentially impacted by the change. This will enable you to fully scope out the impact of the change before it’s made (if you decide to proceed), giving you far more control over the cost and time impact of change requests. This can of course also work in reverse – if a design change is necessary, say because the original design proves infeasible, you can more easily see what impact that has if any on your ability to still meet the requirements. Both of these scenarios have great project management benefits – you can have informed discussions in the development team and with your customer/stakeholders about whether to make the change.
What’s that I hear again – what about agile? Aren’t traceability and the benefits it’s proposed to have only necessary/of value in waterfall development? Well, take another look at that list of benefit scenarios – don’t you always want to be able to do these things, regardless of development methodology? If you’re in a fast changing, evolving project don’t you need to be more informed, have the right information at your fingertips, in order that you can respond quickly but effectively? I argue that if you have the right tools in place to create and utilize traceability, that it is even more essential if you’re adopting agile practices.
Speaking of the right tools, tools can automate the various types of traceability reporting and analysis I described above. For impact analysis, tools can quickly display all of the related artifacts connected to a particular requirement. And more than that they can detect changes in a requirement that has links and automatically mark those links as suspicious. This is very effective where you have different people working on different parts of the application/system and you need to be aware of changes in other areas that might impact your work. A suspect link indicates that a change has been made to the artifact at either end of the link and that you should check that the link still holds true – i.e. if the user requirement has changed, does the linked system requirement still satisfy it? This proactive impact notification mechanism helps to avoid inconsistencies across your specifications.
So you have my views on the uses and value of traceability, but what do you think? Please use the comment function to leave feedback and additional ideas.
I’ll leave you with a couple of links that have additional discussion of the value of traceability and in particular how much traceability is enough:
This is the fifth part of our six part blog posts series on basics of requirements management. Read the remaining parts here -
1. What is requirements management and why is it important?
2. How to write good requirements and types of requirements
3. Why base line your requirements?
4. What is Traceability?
5. The uses and value of traceability
6. Revisiting Requirements Elicitation
CLM 4.0.1 has enhanced its higher enterprise development support with server renames and clustering. CLM 4.0.1 is now supported in Max OS X and also Safari and Chrome supports. Continuing with improving the flexibility when it comes to licensing, we introduced two varieties - CLM Contributor and Practitioner licenses. In 4.0.1, we have extended the workgroup licenses to RRC & RQM also. For a detailed review contact us or your respective account rep.
The biggest addition to RRC 4.0.1 is the inclusion of modules. So what are modules?
Modules helps us in organizing the requirements into ordered lists and use hierarchy to group them. This is in addition to the collections we have presently. This helps Business Analysts to increase control for requirements by group and give teams’ additional meaning, awareness and understanding. Reporting of requirements could be improved significantly with documents with the templates provided.Here is a detailed video
explaining modules in Requirements Composer.
The ability of comparing collections is also now included in RRC 4.0.1. This helps the business analysts to discover differences in project information progress quicker, learn what has changed and communicate across the team.
Ability to better control lock in a multi user environment is improved with an automatic edit lock option. The main utilities of this feature are to lock a requirement artifact while you are making changes or to apply permanent locks to restrict for security/regulation purposes.Here is a video showcasing the feature in detail
We had introduced significant changes based on ReqIF in RRC 4.0. In this release, further improvements are made in terms of the ability to import the requirements into different projects. This enables for example of data transfer between DOORS & RRC; take the data offline to work on etc. We intend to improve the options available for offline data usage in the future releases.
Another significant improvement in RRC 4.0.1 is the RRC-HP Quality Center integration. Now we can directly preview QC tests in RRC. This helps in use of requirements definition and management capability from RRC to manage project requirements being tested using HPQC. The following screenshot showcases a customer using Requirements Composer to view various requirements collections. The user rests his pointer (“hovers”) over one of those collections and a pop-up window appears showing a preview of what’s contained in a test plan that’s being managed by HP Quality Center.
RRC 4.0.1 enables bi-directional connectivity from requirements to models/elements using Rational Software Architect (RSA), Rhapsody, and Design Manger. This seamless integration helps you to use requirements and models together to design and document the project needs.
To read more about enhancements in RRC 4.0.1, visit jazz.net.
To know more about Rational Requirements Composer, visit here.
Modified on by VijaySankar
Note: This is the fourth post in our series of Managing Your Requirements 101. Read the first three posts here:
What is traceability? Or more specifically what is requirements traceability? Well rather than repeat what is already a good collection of definitions, I’ll refer you to http://en.wikipedia.org/wiki/Requirements_traceability
. From there I’d summarize three elements to requirements traceability:
Following the life of a requirement – from idea to implementation
How requirements impact each other, and how requirements impact other development lifecycle artifacts (such as designs, tests, tasks, source code, hardware specs, etc.) and vice versa.
The decomposition of requirements – from high level user/customer/market needs to system, sub-system, software or hardware component requirements; and transformation into design specifications and the implementation realization of the requirement.
Traceability in this context is about relationships between requirements at the same or different levels of detail, and between requirements and other lifecycle artifacts as listed above. It also extends to relationships beyond those directly involving requirements – i.e. the relationship of a defect report to a test case – this is referred to as ‘lifecycle traceability’. Traceability relationships can be of multiple types, for example:
Satisfaction: a system requirement (or more likely a number of system requirements) ‘satisfies’ a user requirement e.g. system requirement ‘The engine shall have at least 200bhp’ satisfies user requirement ‘The car shall be capable of accelerating from 0-60mph in under 8 seconds’.
Verification: a test case ‘verifies’ a requirement e.g. test case ‘0-60mph acceleration test’ (consisting of a number of test steps) verifies user requirement ‘The car shall be capable of accelerating from 0-60mph in under 8 seconds’.
Dependency (often used where interfaces are concerned): a requirement ‘depends’ on another requirement e.g. requirement ‘the power socket shall take 3 pins’ depends on requirement ‘the plug shall have 3 pins’.
Basic traceability establishes a relationship or link between one or more elements. Typed traceability adds the relationship type with its associated semantics (examples above). Rich traceability (ref: Requirements Engineering, Hull, Jackson & Dick, Springer, 2004) adds additional information on the traceability relationship such as the rationale explaining why a group of systems requirements satisfies a particular user requirements; or as is often the case, you can’t be 100% certain on specification or design decisions, you might document any assumptions you made in deriving a set of systems requirements from a user requirement. The rich traceability approach is particularly valuable in heavily regulated industries and safety-critical systems where audit trails of decisions made are vitally important to provide assurance and reduce risks.
Once traceability has been established there are multiple ways in which it can be viewed and reported on. Perhaps the oldest and most commonly recognized method is the traceability matrix where you can see the intersection between two sets of requirements and a check or cross shows where a link exists. This method doesn’t scale particularly well since the matrix could become very large. It’s also sometimes used for creating the links, but it’s not ideal for that either since you can typically only see a small amount of information on the requirements.
Another way to see traceability is to pick a starting point, e.g. the user requirements and display the related systems requirements alongside the user requirement they are linked to, in a traceability column. You can typically choose how much detail of the linked requirement is displayed, and you can even make it recursive, going down as many levels of requirements as you need/is practical to manage in a single view.
Graphical displays are great for getting a bigger picture view of traceability rather than immediately focusing in on the details of particular relationship. You can explore the traceability tree, zooming in/out or collapsing/expanding parts of the tree, or changing the focus (starting point) of the tree.
But what about in agile development, I hear you cry? Well that could be another topic in its own right – watch this space - but relationships still exist between typical artifacts created in agile approaches (such as between product features and user stories), and I argue that as long as traceability is created ‘as you go’ and automated by tools as much as is practical, that it’s even more essential to stay informed when changes are happening rapidly and ensure you are looking at the correct versions of related artifacts.
In a follow-on post in this Requirements 101 series, I’ll take a look at what traceability can be used for – highlighting where its application can bring significant value to your projects. But for now I’ll leave you with a few resources below that I’d recommend you take a look at, and ask you to let me know if you think this post was useful (or not!) and provide any feedback or additional information using the comment function.
Modified on by VijaySankar
Note: This is the third post in our series of Managing Your Requirements 101. Read the first two posts here -
Usually projects start with unclear requirements and expectations. Lack of base lined requirements can result in chaos with lots of requirements changes resulting in requirements and scope creeps. Baselines can also help in acceptance testing and prototyping efforts. Baselines are especially valuable in fixed price contracts.
A baseline is all about getting to a common base agreement between stakeholders. It essentially involves setting the right expectations including responsibilities, risks, assumptions, deliverable and approaches. Once an agreement is reached; it could be put in source control to manage the base line going forward.
Why bother base lining requirements? As mentioned in earlier posts, requirements are the foundation stones to a project and unless we know what we are creating; how do we know what changes to make in due course? Starting the projects without a proper analysis of requirements is a recipe for disaster - it’s like building a house without a blue print. When it comes to software projects, lack of base lines can incentivize clients to make endless changes while the project is in progress and resulting in requirements and scope creeps. Requirements must be initially base-lined and put under change control in the Statement of Work (SOW) so that the project can be planned, estimated and executed. When it comes to a requirements management tool like Rational DOORS or Rational Requirements Composer, a requirements project baseline captures the entire project at a specific moment in time including folder structures and artifacts. Baselines also play a significant role in enabling traceability. It provides the foundation linkages to establish the traceability matrix later in the project.
What to be included in a baseline? Though the contents of a baseline can vary; it is essentially provides the functional and nonfunctional requirements taken into consideration for a release or an iteration. It may contain other aspects like sub system and hardware dependencies also. It is also important to note here that requirements baselines evolve over time. The Business Analyst or Project Manager concerned takes the call on creating new baselines as requirements change or new requirements pops up. As mentioned above, a requirements baseline essentially captures the entire state of a project as t a given point in time. Essentially this includes the vision/scope document, glossary of terms, use case (stories). The starting point for not resulting in requirements creep is setting the boundaries.
Ideal time for base-lining. Baselines drive formal change controls. A project manager is always trying to address the triple constraint – scope, time and cost (coined by Kathy Schwalbe) . Baselines help in managing the scope constraint and focus on other aspects. Baselines also pave way to setting the schedules. Karl E. Wiegers in his book (More About Software Requirements) provides an exhaustive list of factors to be considered before defining a requirements baseline.
What do you think about baselines?
This is the third part of our six part blog posts series on basics of requirements management. Read the remaining parts here -
1. What is requirements management and why is it important?
2. How to write good requirements and types of requirements
3. Why base line your requirements?
4. What is Traceability?
5. The uses and value of traceability
6. Revisiting Requirements Elicitation
Modified on by VijaySankar
This is the second post in our series – Managing Your Requirements 101 – A Refresher. Read the first part here
Requirements are the starting point for everything - project scoping, cost estimation, scheduling, coding, testing, and release management. If the requirements captured doesn’t serve the purpose that are supposed to do; there is hardly any benefit in spending time and money behind it. I remember in Innovate 2012 at Orlando, Arnold Flores from Raytheon speaking about five common traps that results in ineffective and non-verifiable defects - Not understanding requirements, Not having continuous dialogue with stakeholders, Not getting consensus, Not involving other disciplines early and Not limiting scope and requirements creep. Thus good quality requirements should
Establish a common understanding between the project sponsor, customers, developers and other stakeholders
Improve customer confidence in the products to be delivered
Provide a roadmap to development
So how to get the right requirements and make sure they are of quality ones. Some of the official channels that Business Analyst try to get requirements of a client could be interaction with end users or sponsors, business cases, request for proposals, regulations and so on. In a seminal article titled Writing good requirements is a lot like writing good code , Jim Heuman, a Requirements Management evangelist talks in detail about how to write good quality requirements. A lot of articles are available in public domain that talks about how to write good requirements. Essentially the core principles revolve around a requirement being Simple, Verifiable, Necessary, Achievable, and Traceable. We will discuss some of the techniques used to capture requirements later. Provided below are some of the resources that will help you in writing good requirements.
A Business Analyst’s soft skills are equally important to succeed in this endeavor. I am sure you must have seen a similar picture that shows how to what extend understanding the requirements of a customer can go wrong. Some of the common mistakes a business analyst make while requirements gathering and analysis are incorrect assumptions, not using the correct level of abstraction, contradicting and inconsistency between requirements and finally over specifying requirements to a spec level. Even using simple language, avoiding generic phrases and using correct grammar becomes handy while writing good requirements.
In our earlier post, we defined requirements as a condition or capability needed by a user to solve a problem or achieve an objective. Often the client provides a high level requirement in the form of a need. These needs, expectations and concepts must be identified, analyzed and elaborated into a set of business requirements. Key requirements in this set should be traced back to the business case provided relating to the need and client's vision.
At a broad level, requirements could be divided into functional and non-functional requirements. Functional requirements provide the high level description of how a system of product should function from the end user's perspective. It provides the essential details of the system for both business and technical stakeholders. Expectations are expressed and managed using functional requirements. Some of the key aspects functional requirements try to address are for whom the product is built, how is it expected to be used, what are the interactions and any guidelines to be followed. Non-functional requirements represent mainly the qualities (expectations and characteristics of the system) and constraints (for example Governmental regulations).
When it compared to requirements levels - we can start with the Requirements Pyramid as shown below(from Requirements Management Using IBM Rational RequisitePro by Peter Zielczynski
). It essentially starts from the stakeholder needs at the top to the test cases that verify the implemented requirements at the bottom.
A requirements plan captures all these information. For a template, click here
This is the second part of our six part blog posts series on basics of requirements management. Read the remaining parts here -
1. What is requirements management and why is it important?
2. How to write good requirements and types of requirements
3. Why base line your requirements?
4. What is Traceability?
5. The uses and value of traceability
6. Revisiting Requirements Elicitation
Modified on by VijaySankar
The world of requirements management has developed significantly in the last decade or so and has increasingly become one of the corner stones of successful software and systems engineering projects. We have been discussing various aspects of the domain from a best practices perspective and how tools can help managing your requirements efficiently and effectively.
Starting today we will discuss various aspects of the requirements management discipline at a bird’s eye view level. These are meant to be introductory in nature and also intend to serve as refreshers for those who are already in the field. The domain and best practices have developed to an enormous level of sophistication that; it is difficult to cover everything in a set of blog posts. However we intend to make these posts as a quick reference and starting point for you to think seriously about the domain.
Have you heard about the Gaudi’s unfinished Cathedral or Airane 5 explosion? The former one is a hundred year project still under progress which couldn’t be finished because of unclear and changing requirements
and the latter one resulted in over $7 billion loss when the rocket exploded on its first voyage due to a software error; specifically floating point number error
. The importance of requirements management can be established from three unique perspectives – project overshoot and thus missing the market opportunity due to unclear and changing requirements; project failures due to unmet or misunderstood requirements and finally cost burden due to errors and missed requirements found late in the development cycle.
In a classic IEEE Spectrum article, Robert N. Charette writes about Why Software Fails
. Among the top reasons for failure of software projects are poor definition of requirements, poor management of risk, communication failure among stakeholders and increasing complexity of projects. In IBM GBS, ineffective requirements managements in one among the top five reasons for troubled projects. Many research firms (Standish Group’s CHAOS report, Gartner, CMU-SEI) and academicians (A Davis, Robert B.Grady, Steve Easterbrook
) have studied and quantified the failure rates of software projects (for example, in the above IEEE article Robert opines that 40-50% of software development time is spent on rework and cost of fixing a bug in the field can be as high as 100 times compared to when fixed at development stage). In all of them, the preliminary reasons for failures or overshoots are ineffective management of requirements.
So what exactly is requirements management?
Before moving to requirements management, let’s understand what a requirement is? A requirement can be anything from an abstract need to a well drilled down implementation detail of a system. Essentially it can be considered the detailed view of a need under consideration. IEEE Standard Glossary of Software Engineering Terminology
defines a requirement as a condition or capability needed by a user to solve a problem or achieve an objective; or a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents; or a documented representation of a condition or capability as in former two. Thus what a requirement essentially represents depends on to whom we are talking to – it could be the need to a client; a business requirement for customers; a system requirement for vendors or a specification for a developer and tester. We will come to the different types of requirements later. Requirements Management can be considered the management of requirements essentially from when a customer provides the needs or a product development process is started. It includes managing the definition, elaboration and changing requirements during the development cycle and systems development. Peter Zielczynski, a requirements management expert defines the following major steps in requirements management (Requirements Management Using IBM® Rational® RequisitePro®, Peter Zielczynski
Establishing a requirements management plan
Developing the Vision document
Creating use cases
Creating test cases from use cases
Creating test cases from the supplementary specification
Zave (Classification of Research Efforts in Requirements Engineering. ACM Computing Surveys (1997)) defines Requirements Engineering as “the branch of software engineering concerned with the real-world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behavior, and to their evolution over time and across software families.” While in practical terms, this could be considered same as requirements management, we can say requirements engineering addresses various aspects of requirements development; requirements management is the set of processes in systems and software engineering that interfaces with requirements engineering. We will try to delve into more details in another post when we consider V&V (Verification & Validation) model.
This is the first part of our six part blog posts series on basics of requirements management. Read the remaining parts here -
1. What is requirements management and why is it important?
2. How to write good requirements and types of requirements
3. Why base line your requirements?
4. What is Traceability?
5. The uses and value of traceability
6. Revisiting Requirements Elicitation
As another year comes to an end, we wish you all a happy and prosperous new year!
2012 was an eventful year with major releases for both Requirements Composer
. We announced the next generation requirements management solution for complex & embedded systems from IBM - Rational DOORS Next Generation
We moved to deverloperWorks platform for our blog. We believe our readers found this blog useful. Please share with us your comments and suggestions for the blog content and also any specific topics in requirements management
that you want us to focus on in 2013....
Last but not least, as we mentioned in the last post, call for speakers in now open for Innovate 2013 - The IBM Technical Summit
. Submit your abstracts before January 14 2013 to stand a chance of presenting in a conference with 4000+ footfalls and a free conference pass!Happy New Year!
Innovate 2013 – The IBM Technical Summit is here. The 2013 event promises to be even more exciting with top-notch keynotes, over 450 breakout sessions, labs, certifications and our biggest exhibit hall ever. As in previous events, Requirements Management is one of the key areas of interest at Innovate which attracts speakers and attendees from across the globe representing a wide range of industries. In 2012, we had two tracks for Requirements Management with sixteen sessions each with one track focusing on IT and another focusing on Systems Engineering. We had 14 real life case studies, 2 panel discussions and 4 instructor led sessions.
Managing requirements has always been a cornerstone in both software and systems development. The importance of the discipline continues to grow and is expected to take a leading role in the coming years. This is an opportunity to showcase your thoughts on the discipline, and how requirements management tools like DOORS or Requirements Composer can aid in managing effectively the requirements for project successes. Here are some of the topics from last year and an expected list of topics
- Requirements Management in Agile Projects
- Requirements Management for Mobile Development
- Managing requirements in developing Safety Critical Systems
- Developing and managing requirements specifications for contract agreement
- Requirements Driven Development: Understanding requirements and work items
- Requirements engineering and supporting layered requirements and models
- Delivering a specification perfect requirements set (document generation)
- Requirements Reuse: Methods and best practice
- Requirements management for complex systems and teams
- Using traceability to expose gaps/change to other requirements and across the lifecycle
- Requirements engineering for projects with complex systems and software
- Requirements definition and management case studies
- Requirements definition and management across the software lifecycle
- Elicitation techniques for requirements and use cases
- Agile software development and requirements modeling
- Requirements management for outsourced projects
- Defining and managing requirements across geographically distributed teams
- Metrics and analysis used in requirements management
- Integrating requirements with project and portfolio management
- Implications of regulatory compliance on the requirements management process
- Business specification-centric approaches
- Best practices in aligning business goals and IT
- Value-based requirements engineering
- Business modeling in requirements definition
- Requirements prioritization best practices and choosing your methodology
- Incorporating industry standards as reusable requirements
- Effective reporting using requirements and CLM information
- DOORS, Requirements Composer and other Rational products best practices
- Requirements engineering and product lifecycle management
Some session topics from Innovate 2012
- Iterative Requirements Analysis: Implementing Lean and Agile principles for Software Requirements Analysis (Nationwide Case Study)
- Visual definition in the requirements lifecycle: a conceptual framework
- How IBM Rational DOORS Helps JPL Get to Mars and Beyond: Best Practices in Metrics, Verification and Traceability
- Integrating IBM Rational DOORS with IBM Rational Team Concert – Lessons Learned at Raytheon
- Integrating Requirements and Models with IBM Rational DOORS and IBM Rational Rhapsody: Lessons Learned at Lockheed Martin MS2
- Writing Verifiable Requirements Is Not Easy
Share your experience, thoughts and best practices on requirements at an event attended by industry experts and IBM core development teams. Here are the top three reasons on why you should submit your paper for Innovate 2013.Explore
new areas - Free conference pass opening up the doors to 450+ sessions, labs and demo boothsNetwork
with experts and peers - Over 4000 professionals expected to attend the eventSharpen
your technical know-how - Learn from product and domain experts and from IBM core developers
As we reach the close of a year and move into a new one,
it's often time to take stock of what we've been doing and making plans for the
New Year. We look at what we've been doing right and what we could change and
improve. So since this is a requirements management blog I thought it would
worth posing the question and giving an opinion on whether requirements
management (in the domain of systems and product development - my focus area)
is still relevant today and as we move into 2013?
I'm not really sure when requirements management as a formally
recognized discipline can be said to have come into being, but I do believe that
it really started to take shape in the early 90's, primarily based on work
coming out of the aerospace industry, and that's when commercial specialized
tools for requirements management, such as IBM Rational DOORS (then known
simply as DOORS from a company called QSS), first emerged. In 2005, I was leading
a team working on a campaign to promote the value of requirements management to
a wider audience than a core set of requirements specialists. We declared
2005 as the 'Year of Requirements Management' because of its increased
recognition as a discipline and the emergence of greater
tool capabilities for making requirements more easily accessible to a wider set
So as we move towards 2013, is requirements management still
as relevant? Do we still have further to go on becoming more effective at it?
In a recent Aberdeen Group report ‘Managing Systems Design Complexity: 3 Tips to Save Time’ by Michelle Boucher, where a survey of the effectiveness of systems engineering
capabilities of system and product development organizations is reported, two
of the three key recommendations made are directly related to requirements
management in the areas of visual requirements definition and requirements
traceability. In the other recommendation on improving change management across
engineering disciplines, Michelle says that impact analysis is core to such
improvement and that’s enabled by requirements management and traceability. From
study, a clear link can be shown between more effective requirements management
and traceability to business benefits such as reduced cycle times, improved
quality and increased product revenues. I also recently heard from another
analyst that one of the key challenges they are hearing from product
development organizations is getting a better handle on interrelationships
between requirements across engineering disciplines, so they can respond more
effectively to changes.
So my answer to the question I posed of is requirements
management still relevant is a resounding YES! We’ve made significant progress
but complexity of the systems we build has also increased and we need to keep
pace with changes in practices and technologies, so I expect effective
requirements management to remain a cornerstone of successful product
development and for practices and supporting tooling to continue to evolve.
But what you do think? Will requirements management be as
important in the future? How will it/should it change?
Last week the UK chapter of INCOSE (International Council on Systems Engineering) held their annual systems engineering conference on the Warwick University campus. I'd like to share some of what I heard during the conference, both on systems engineering in general, and more specifically on requirements management practices in the systems engineering domain.
One of the keynote speakers was Dr Sandy Wilson, President & Managing Director, General Dynamics UK. Dr Wilson spoke about the key challenges in the defense industry - the rate of change in threats and technology and the need to lower costs. He challenged the V model - said it's a nice diagram but its linearity is an issue - the world is not linear or rigid but the SE V diagram is. He spoke about the need for the defense industry to become more agile but that today change is cumbersome due to contractual issues and governance constraints. There are two main types of defense procurement done in the UK - the longer term needs are met by EPs (Equipment Programmes) and the urgent tactical needs by UORs (Urgent Operational Requirements). The former is bogged down in top level scrutiny and check boxes. The latter is helped by the top level sense of urgency and support. An example of a UOR was the decision to implement the multinational no-fly zone over Libya. Dr Wilson proposed that all defense projects should become more like UORs - more agile. He said that "an 80% solution delivered 1 year earlier is better than 90% delivered 4 years late". I heard that delivering incremental capability needs asset management and tracking, configuration management and a more agile approach to systems engineering - valuing "Product over Process". As well as changes in the way companies deliver capabilities, a change is needed in the way the customer (governments) do their acquisition and contracts in order to enable more agility.
Dr Jeremy Dick of Integrate Systems Engineering
and co-author of the book 'Requirements Engineering' presented a case study in the aerospace industry on developing the assurance case for a (safety) critical system in parallel with requirements analysis, design, verification & validation, using an extension of his technique for documenting the rationale for traceability relationships known as 'rich traceability'. In addition to developing a requirements 'flow-down' (through levels of requirements to design), the 'evidence' supporting the flow-down is documented. The evidence in the early stages can be how you expect the lower level requirements or design elements to satisfy the higher level and your evidence to suggest that your argument is sound. In parallel your verification & validation strategies should be evolved, including an argument and supporting evidence for how the test(s) will prove the requirement(s) is/are met. Jeremy was asked how the textual requirements, arguments and evidence would fit with a MBSE (Model-Based Systems Engineering) approach. Jeremy answered that he favours (and in fact came up with the concept of - ref: "The Systems Engineering Sandwich: Combining Requirements, Models and Design", Jeremy Dick, Jonathon Chard, INCOSE International Symposium, Toulouse, July 2004) the sandwich model - interleaved layers of requirements and modeling used to decompose a system specification adn design (you can read more on that concept in the post 'Food for thought: The Systems Engineering Club Sandwich'
Chris Rolison, CEO, Comply Serve
, continued the theme of progressive assurance with focus on the rail industry. Chris highlighted the complexity challenges in major rail infrastructure projects, and the issues presented by paper-based systems, silos in organization structures, and the supply chain. Chris said that "up to 80% of the engineering requirements can change during design & build" - not because the customer changes their mind but because of all the external factors involved in building a rail system. Chris went onto describe a more collaborative, requirements-driven design approach where systems engineering principles are applied, supported by a collaborative platform (ComplyPro which is based on IBM Rational DOORS).
Alastair Mavin of Rolls Royce 'lent' us his EARS (Easy Approach to Requirements Syntax
(link is to an IEEE publication - sign in required) an application of a template with an underlying rule set on how to describe requirements using natural language but in a more structured, consistent way. He described the latest version of the template EARS+ (or as he nicknamed it 'Big EARS' !) and the benefits of the approach - simplicity and structure combined.
I could go on for pages about all of the great content shared at this excellent event but I'll leave it there with the main requirements related topics, except to quote from the keynote speaker on day 2: "The core of Systems Engineering is defining requirements and delivering against them". I'd put it this way - you can't have successful systems engineering without effective requirements management.
Neal Middlemore has over 14 years of experience in requirements management, this encompasses the associated disciplines of change management of requirements and validation/verification. Neal comes from an avionics systems engineering background and has been working with the DOORS product for over 10 years.
One of the most fundamental benefits that businesses want to get from using requirements management tools is consistent traceability. It doesn’t matter if it is an IT system being developed or an aircraft carrier, the levels of complexity being dealt with determine that traceability across multiple levels of requirements, from stakeholder requests to detailed implementation, is not simple to maintain manually.
Further hurdles are put in our way by the need to comply with legislative requirements, so many different industries these days have requirements placed upon them by government and international standards bodies along with internal corporate standards.
To prove compliance with these legislative rules it is necessary for projects to not only prove that requirements are being managed but also to provide the how and where of their management. What features relate which stakeholder request? What aspects of the solution satisfy safety regulations? Has the realization of the requirement been tested and by whom on what platform?
To answer these questions it is necessary to utilize the traceability capabilities provided by modern tools but it’s not enough to let a tool decide how things relate to each other, it isn’t enough to let individual users decide these relationships. Traceability needs to be considered in the larger context of how you report on it to answer the very questions that led you to consider traceability for in the first place. It’s more than ‘does object A relate to object B?’.
An initiative to define an information architecture of your governance solution will assist in defining your process artifacts and their relationships to one another. Traceability becomes an asset rather than an overhead. A good way to begin such an initiative is having a workshop attended by all project stakeholders i.e. those who have a vested interest in ensuring project success. Most likely these attendees will have a good understanding of the process and what the project needs to deliver. Undoubtedly each will also bring differing perspectives and understanding of what information is required.
The test manager may want to see traceability from individual test artifacts through to the requirements being tested or to determine regulatory compliance has been achieved and whether verification methods have been agreed.
A subject matter expert (SME) may want to see the design in the context of the system level requirements and how it relates to stakeholder requirements.
Everybody wants to see something that is applicable to their job roles, even wishing to see things outside of their typical discipline domains. By asking the questions and documenting the answers you can start to put together an information architecture that makes sense for your project. It’s likely that many information architectures will exist. Not every project is the same and these will have differing sets of required attributes, views and reports of project information and agreed structure of inter artifact relationships.
Modern tools can often create templates for this kind of information to allow the deployment of additional artifact containers as and when required. These can even enforce traceability to ensure the integrity across the project. Above all, it is vital that the needs of the project is documented and communicated alongside of the information architecture to all project members.
Eric has worked in the software development industry for over 20 years and is co-author of UML for Database Design and UML for Mere Mortals both published by Addison Wesley. Eric is currently responsible for capabilities marketing of Rational’s application lifecycle management solutions including Agile Software Delivery, Quality & Test Management, Requirements Management and Collaborative Lifecycle Management. He rejoined IBM in 2008 as the team leader for InfoSphere Optim Solutions and later was responsible for Information Governance Solutions. Prior to rejoining IBM, he worked for Ivar Jacobson Consulting as VP of Sales and Marketing. Before joining Ivar Jacobson, he was director of product marketing for CAST Software. Previously working for IBM, Eric held several roles within the Rational Software group including program director for business, industry and technical solutions, product manager for Rational Rose and team market manager for Rational Desktop Product. He also spent several years with Logic Works Inc. (Acquired by Platinum Technologies and CA), as product manager for ERwin.
As I think about IT today, there comes a rebirth in some ways of the importance of architecture and requirements. We are in an era of “ANY” -- meaning that applications and data can be accessed from anywhere, by anyone, and at any time.
Looking back at the applications of yesteryear (two or three years ago), we didn’t expect much from the web or mobile-based applications. We could view, run some reports or do some basic tasks, but to do the real work, we needed to go to the fat-client. Now, in today’s era of any, the user interface may look different, but the capabilities had better be the same since we expect near full capabilities no matter our device or interface.
This puts a new found set of requirements on applications and their development, and is making modeling and requirements (analysis and design) relevant again, but with a new twist – AGILITY. It is no longer a question of “what platform am I developing for” – the question is how quickly can we get it up and running on the latest version of Apple, Android, HTML 5 and whatever other platforms our clients expect the application to run on … and it had better run on all of the latest versions, with no delays, when updated operation systems come out.
And the question that I often receive now, however, is “can I be agile and meet these needs at the same time”? The plain answer is, yes, you can. However, agility doesn’t me you cannot ignore requirements and design. I am not talking about write-once, run-anywhere, rather instead understand the true requirements so that the various development teams can articulate them in code brought to life as features for the users, as they expect to see them. Users are looking for the application to be specific to their hardware/OS (iPad/AppleOS, Droid/Android…) as the hardware has become the platform for not just running the application, but the expected look, feel and usability of it now, too. This often means different developers for different deployment platforms, certainly at the User Interface level.
Designing applications requires that we are prepared. Architectures must be solidified and communicated. Requirements must be consistent and shared. We must model architectures so that developers can build to the designs and not recreate their own, wasting time and resources, and we must share those designs across the team.
Does this get in the way of agility? NO, it will speed agility. By sharing designs, assigning tasks based on architecture needs, we can speed time to market and our ability to deliver high quality software. In the era of any, we may have multiple teams working on the same front-end capabilities for different platforms even though the back-end is the same. But the more they can share, the faster they can be deployed and having the right requirements from users, the more satisfied they will be. We see people changing their desired platform as employers, vendors and suppliers change requirements, so we need to be prepared for the customer who is using an iPad today to be using an Android device tomorrow with the same requirements on the application. Just look at how the world of Blackberry has evolved.
So, as you think about your next project, don’t skimp on requirements and architectures or you may be limiting your agility in the future rather than speeding your time to satisfied clients.
Nowadays, software is present everywhere and software projects are becoming complex in terms of scope, time and cost. Associated with such a change increases the potential failure rate of software projects. How can these potential failures be avoided? While a guarantee may not be possible, adequate investments in managing the risk of failure can be provided. A typical textbook definition of software risk management is the identification of risks, analysis of identified risks and establishing plans to address those risks. The important goal of risk management is to avoid the occurrence of such risks. Similar to requirements management, risk management needs to be started early in the development life cycle process.
ISO/IEC 16085:2006 defines risk as a combination of the probability of an event and its consequence. What are the major sources of risks in a software project? An obvious answer to that question today would be the prevailing uncertainty added by time and budget pressures. Inaccurate requirements capture, is another important reason for increased risks in the later stages of the life cycle. Boehm
has done some phenomenal work in managing risks in software projects. He essentially identifies ten risk aspects – Personal shortfalls, unrealistic schedules & budgets, development risks (building wrong functions, properties or user interfaces), adding unnecessary features, continuing requirements changes, shortfalls (in externally furnished components & performed tasks), performance shortfalls and technological strains.
So how do you best manage the risks?
– Boehm divides the first level of activities into Assessment and Control. Assessment essentially contains identifying the risks, analyzing the identified risks and finally prioritizing the risks. Control aspect deals with planning, resolution of identified risks and monitoring. If you consider the Top 10 items he has identified, requirements mismatches, requirements changes and architecture performance & quality are among the top. Various techniques are discussed in Risk Management literature which is beyond the scope of this blog post. These techniques involve basic ones like maintaining a risk register to decision tree analysis
, to risk exposure profiling. Murray Cantor, a Distinguished Engineer at IBM regularly writes about risks in his blog here
What are some of the generic strategies to managing risks? – The predominant method is to buy more information; for example if you are in the early development cycle, you could always try prototyping to make sure you and your client are on the same page of understanding. This also helps in revealing the possible root causes of risks. Other options are to avoid the risk by de-scoping requirements, transferring it (for example outsourcing the component to an expert vendor or a sub-contractor), have mitigation plans or as the last option, accept the risk and have a Plan B. ISO 31000:2009, a relatively new standard introduced in 2009 related to risk management, provides a generic framework for a risk management process which a team can consider implementing.
How can tools help manage the risks?
Risk includes both opportunities and threats - that is a risk can have both a positive and negative effect. Tools help in implementing an integrated risk process that enables maximization of value creation resulting in faster time to markets and improved productivity, at the same time avoiding the threats of cost and time over run and project closures. Tools can help significantly in two ways - conducting the qualitative and quantities risk analysis activities and actually implementing the outcomes for managing risks. Check this case study of Chubb Insurance
that manages effectively its risk using IBM Rational Focal Point. And finally here is a developerWorks article on how to calculate your return on investment for software and systems
You've bought the plot of land for your dream home. You have your list of requirements - 4 bedrooms, 3 bathrooms, spacious kitchen, 2 living rooms, 2 garages, landscaped gardens, etc. Would you be happy to simply hand that list to the builders and let them start work? Unlikely, I think. Typically, you call in an architect, who can take your quantitative requirements and qualitative desires and produce a blueprint, the architectural design that incorporates your wishes where feasible and adds creative flourish based on the architect's knowledge of house design. The blueprint enables you and the builders to have a much clearer picture of the desired end result than that original list of requirements. And it affords you the opportunity to influence the architecture, and for the builders to question and look at feasibility & cost options, before the foundations are dug and the first bricks are laid.
The same applies in product development. Systems engineers who are responsible for the holistic product specification and design don't just use textual requirements lists to capture the problem domain and describe the proposed solution. They analyze the requirements, identifying integrated scenarios, and often depict those using modeling languages such as UML or SysML. These modeled scenarios are easier to discuss and review with all stakeholders, and as the systems engineer evolves the proposed architecture (also in the same modeling language) they can run the scenarios against the architecture in model simulations to find inconsistencies or gaps in the requirements and flaws in the design, long before any software is coded, circuit boards are soldered or metal is welded.
So what value are our textual requirements lists - should we throw them away in favor of models? Well, not everything can be expressed in the model and not everyone involved in a development effort maybe using models. Going back to the house building analogy, there are contracts, numerous standards and regulations to be adhered to, and simply details that would make the blueprints unreadable. The various contractors (and I know from recent experience that sub-contracting is the name of the game in house building these days!) involved in the building process need to ensure that they can meet the contractual and regulatory demands while delivering against the architecture. Again this is the same in product development, except in many cases, particularly safety-critical systems, traceability and demonstration of conformance to requirements and compliance to standards & regulations are demanded. This requires the ability to integrate requirements and modeling workflows, easily link requirements and design elements, and to report on that linked information.
The need and solutions for this capability are nothing new. Integrations between requirements management and modeling tools have existed for many years (I think I started using such an integration in the early 90's and I'm sure they preceded that time). But I know from first hand experience of using and indeed writing such integrations that they've not always been optimal in the way integration is performed and in the workflow that is supported. Typically it's meant synchronizing (i.e. copying) data between tools in order to create the traceability links in one of the tools. This brings up all sorts of issues like 'which tool is the master?', 'am I looking at the latest data?', 'what happens when information is deleted?', etc.
With Open Services for Lifecycle Collaboration (OSLC
) we now have a much better way to link data across product development and operations tools, even when the tools maybe from different vendors, open source or in-house. OSLC has learnt from the principles of the World Wide Web and enables
tool data to be shared and linked where it resides (called a ‘Linked
Data’ approach). OSLC provides a common vocabulary for ‘resources’ in
particular domains, i.e. what a requirement, test case, design element,
change request, work item, etc. looks like, so that regardless of tool,
technology or vendor, tools implementing OSLC specifications can share and link data.
With Rational DOORS 9.4 and Rational Rhapsody 8.0 with Design Manager 4.0, IBM is utilizing OSLC to provide a simplified workflow for linking requirements analysis and design. On September 20, Paul Urban (if you've been wondering about this blog post title, now you know the Paul I'm speaking of), Market Manager for IBM Rational Rhapsody, presented this simplified workflow and its benefits on a IEEE Spectrum webcast sponsored by IBM. You can watch and listen to the replay at your own leisure here
. I hope you it enjoy it - please let Paul and I know what you think by leaving feedback on this blog post.
The importance of communication and collaboration in developing and managing good requirements were discussed in our earlier post on How to enable effective requirements communication and collaboration
. In this guest blog post, Melissa Robinson - a Senior Technical Specialist at IBM writes about how Rational DOORS addresses this aspects with Discussions. Melissa started her career at Telelogic enabling Product Management with technical support around requirements management. Melissa spent 3 years supporting clients getting started with Requirements management at Telelogic. After IBM acquired Telelogic in 2008, Melissa transitioned roles to support clients with Enteprise Architecture initiatives. She received the Carnegie Mellon certification in Enterprise Architecture in 2008 and is TOGAF certified. Melissa now supports clients getting started with evaluating and implementing both requirements management and enterprise architecture solutions.
Note: Please click on the screenshots for a better view
Why did we make this decision? Who made this decision? Who approved this requirement?
These are some of the questions we can help answer with effective collaboration messaging with DOORS. Collaboration messaging is now enabled in DOORS and DOORS Web Access (DWA) with the addition of DOORS Discussions. Discussions allow users to contribute and add comments to requirement objects or requirement modules, users can even add comments to base-lined requirements. Discussions offer a method of having a conversation on requirements. DOORS discussions really break the communication barrier by allowing users to easily make comments or start a discussion on any requirement, including read-only requirements. Discussions can be created in DOORS or DWA and viewed in both DOORS and DWA. Both DWA Editor and DWA Reviewer roles can contribute to Discussions. Discussions capture comments so that you can later review ancillary information about your requirements. Discussions allow everyone to contribute comments and provide a full understanding of requirements.
Here is a simple scenario for using DOORS Discussions. A DWA Reviewer user creates a Discussion on a requirement. A DOORS user then reviews this comment and contributes a comment on the requirement. The DWA user reviews the latest comment and closes the Discussion.
A DOORS user, Susan, reviews the current Discussion created by a DWA Reader user, Kavita. Susan can open the requirements module with a pre-created Discussion view to review the Discussions. Below Susan reviews the Discussion on Requirement AMR-STK-66.
Susan can contribute a comment to the open Discussion.
Kavita reviews the new Discussion comment in DWA. Notice that Kavita is a Reviewer in DWA. As a Reviewer, she can create and add comments to Discussions. Kavita can also close Discussions that she started. Later, Kavita can contribute another comment to the open Discussion.
As the person who first opened the Discussion, Kavita can close this Discussion.Later, in DOORS, Susan can review the latest status of the Discussion using the Discussion Thread view. As a Database Manager role, Susan can choose to re-open the closed Discussion at any time.
Discussions open up the communication thread between several different types of DOORS users. Discussions allow requirements reviewers to exchange views and comments about the content of a requirements module or the content of a requirement object in a module.
We believe the post gave you a sneak preview of how DOORS Discussions help in effectively collaborating and communicating between various stakeholders during requirements management. Feel free to contact melissarobinson[at]us.ibm.com if you have any queries about the topic. Melissa will be discussing the topic in detail in an upcoming webcast on October 5, 2012. Don't miss the opportunity to watch the action live.
Register now @ http://bit.ly/DOORS_Discussions
There is no doubt that the evolution of computing has moved into the era of the mobile device and any business that wants to remain competitive in an increasingly difficult economic environment needs to embrace this with the care and attention it deserves.
With over a million devices being activated every single day it is predicted that by 2013 mobile phones will overtake the PC as the most common web access device worldwide!
Companies that simply try and tweak their existing web sites to run in mobile browsers are missing a trick as users expect very sleek interfaces that make use of their devices capabilities such as Geo-location and camera. With this in mind the perceived quality of the application comes from both its functionality and perhaps more importantly the design. The design of the applications user interface is also critical when trying to improve brand loyalty and therefore businesses are keen to see their brand image extended to mobile devices where they can reach a much wider audience.
So where does Requirements Management fit in?
Well, a good requirements management process that is incorporated into the wider development life cycle will allow the business to communicate exactly what is required of the mobile application; enabling the development team to be clear on what needs to be created, and for testers to begin writing test cases earlier in the lifecycle. With the need for good user interface design it is important that requirements are not purely textual and so with tools like Rational Requirements Composer
, Business Analysts can model Use Cases, Business Processes and also visualize the user interface through UI Sketches, Screenflows and Storyboards. This means the business can be very clear on what the expected result should be and remove any unnecessary ambiguity that only slows down development and ultimately prevents applications going to market quickly.
One significant trend in the development of mobile apps is the adoption of Agile methodologies such as Scrum, which fits in well with the short timescales and rapid change and release management that mobile apps have. This makes it even more important for the Requirements Management process to also be agile and allow greater collaboration not only within the Business Analysts team, but also with the other teams involved such as development and testing. A web based requirements management tool like RRC encourages wider engagement with stakeholders and also provides dashboards with live information, collaborative reviews and reporting to promote visibility and allow decisions to be made quickly and effectively.
Traceability is one of the corner stones of good Requirements Management, because without it you cannot determine if the resulting product has actually satisfied the original requirements outlined by the business. RRC is a part of the wider solution called Collaborative Life cycle Management and allows the requirements to be linked to the resulting development work items and associated test plans, test cases and defects. This means that from any given requirement you can see exactly what development task is going to implement it, which test case is going to test it and what defects were found in relation to that requirement.
In summary, mobile application development is an exciting and important part of any business plan and due to its inherent complexity you really need the right tools to make it a success.
I am sure you would have seen a graphic similar to this depicting the communication gap between stakeholders in a project and its consequences. Today projects are getting increasingly complex, teams involved in them are often distributed and delivery time is getting reduced. Faster to market has become the major contributing factor to success for most of companies. Being unable to finish development on time and budget and thus missing opportunities is a vexing problem for organizations.
Clearly articulating stakeholder business objectives and requirements for application and product development gives the much needed head start to optimize end results; however tackling the challenge of managing effective communication between development teams and providing a mutually supportive collaborative environment helps ensure a successful project completion. Studies conducted by IBM have shown an improvement of 15-35% in team productivity with the help of effective collaboration. There are two aspects to communication – how to engage stakeholders and how to manage internal team communication.
Managing stakeholder communication
It’s imperative to engage stakeholders early on to get the requirements right. If you are an agile project environment, having consistent involvement of stakeholders becomes even more important and challenging. Providing stakeholder access to the project environment with appropriate levels of access enables this. Thorough requirements definition practices involve understanding as many specifics as possible and should start at the very beginning of the project.
Managing inter-team and stakeholder communication
Unifying stakeholders and the project team, helps to ensure that project goals are met and averting the potential impact that being late to market can have on the bottom line. Up-front visual and textual requirements elicitation techniques to build stakeholder consensus, for example, coupled with full requirements traceability across the life cycle, helps cut risk and the cost of rework from unclear, ambiguous or changing requirements. In the end, this can help improve the time to value and quality. Ralph R Young (Effective Requirements Practices) identifies three root causes for requirements related issues – wide disparity between stated requirements by customers and the real requirements expected ineffective requirements practices in supply chain and finally the lack of joint customer/supplier responsibility for the project success.
While the personal communication tactics like brainstorm meetings and knowledge sharing sessions can add immense value, the present day globally distributed environment requires more day-to-day closely knit solutions for communication. The requirements tool used should ideally have the capability to address a wide set of requirements information beyond the requirements themselves: business context, aspirations, considerations, and business and technical constraints. Capabilities like shared repository, simultaneous view of what team members are working on open issues, group conversations about requirements, and online reviews & approvals can significantly improve communication in the team and increase productivity. Linking requirements artifacts to related information in a repository, and embedding artifacts into documents and user interface sketches (empowering for rapidly refining ideas) have significant advantages. Also, this broad and flexible approach enables teams anywhere in the world to collaborate, clarify and achieve consensus quickly about the requirements as they develop business driven solutions.
Clearly, with geographically distributed teams, teamwork has new dimensions. If an organization gets collaboration right, it can potentially drive higher levels of productivity—and innovation
I was lucky enough last week to travel to the INCOSE
(International Council on Systems Engineering
) International Symposium 2012
near Rome, Italy.
An excellent opportunity to meet the systems engineering community and hear
about their interests and concerns. We had lots of traffic to the very stylish
IBM booth where we talked about the IBM Rational solutions for systems
engineering and the latest from IBM Research on tool interoperability and
design optimization & trade-off. I’d like to claim the traffic was to due
to my presence but in fact there was lots of excitement and interest in the
must have giveaway of the conference, the IBM Limited Edition of Systems
Engineering for Dummies book
(if you weren’t there and don’t have a copy, you
can download a PDF version
Being at the INCOSE event reminded me of the very active and
I recently provoked on the INCOSE LinkedIn group with the posting of the link to my
previous blog post ‘Traceability – How Much is Enough?’
It’s a great read with some very provocative statements about whether
traceability is at all useful and that it’s the root cause of failure on
projects that overrun and overspend versus those that say it’s absolutely vital
on safety-critical systems or where the project is contract-driven. In the end I
think some consensus was reached between these two camps that ‘just enough’
traceability to keep a project on track, provide customer/market need context
to engineers, facilitate impact analysis, and (if needed) to meet industry
standards and regulations, is sufficient. Any more is excessive and wasteful
and likely to bog down progress towards to delivering innovative products and
During a quiet time at the IBM booth, I also had chance to
chat with my colleague Brian Nolan (marketing manager for aerospace &
defense industry at IBM Rational) about effective traceability, since Brian
is very interested in this topic and has presented on a Dr Dobbs
webcast on ‘3 Ways to Improve Traceability and Impact Analysis’.
Brian believes in what I would describe as ‘traceability by design’, meaning
that traceability is automatically established while you decompose your system
design (for example, use case to use case realization to sequence diagram and
so on). This discussion also reminded me of what another colleague Greg Gorman
(program director for IBM systems and software engineering solutions and the
INCOSE Corporate Advisory Board member from IBM) described several years ago as
‘link while you think’, meaning traceability is created by the tools, while you
are performing requirements decomposition, design and development, rather than
as an overhead activity afterwards.
I think we’ve now moved some way beyond ‘link while you
think’. While an information model with ‘just enough’ traceability for your
project needs is essential to avoid traceability spiraling out of control, with
new approaches such as Linked Lifecycle Data
from the OSLC (Open Services for Lifecycle Collaboration) community
and tools that recognize implicit traceability, provide
new ways to visualize lifecycle traceability and perform effective impact
analysis, we can make traceability work for us to help engineering become more
agile, while staying within costs and schedule and produce innovative, higher
quality products and systems.
We had an interesting webinar with Mary Gorman, EBG Consulting on whether Business Analysis is required in agile projects? Mary talked about lots of concepts and put forth her case on how business analysis is essential for agile success. If you didn't attend the webinar, an on demand replay is available here
. Also read our interview with Mary on this topic here
Mary shared with us five agile business analysis actualities that are key to agile project successes. Two of them stuck my mind – delivering valued products and product partnerships. Often we tend to forget hard questions like to whom our products are most valuable and what is the potential of our products? Mary Gorman shared a simple value equation with us
Value = Increased Revenue + Avoid Cost + Improved Service + risk
If we are to provide value to our customers, we have to concentrate on each of the factors above. Increasing the revenue stream can be through either creating new streams or protecting the existing ones. Software tools can play a role in avoiding cost through increasing operational efficiency to improve time to market. Improving the service could mean increased usability and accuracy. Coupling these factors with risk and dependencies and looking at the balance is very critical for providing a valuable product.
The role of partnership and collaboration is increasingly becoming important and this was once again stressed by Mary with her opinion of analysis is everyone’s job and is a continuous process. At IBM we believe that a collaborative requirements definition & management capability that is linked with other critical lifecycle disciplines such as test management are essential for success in agile business analysis, particularly where you may have large, distributed teams and/or regulated environments.
The webcast also discussed other agile business realities like the importance of discovering product needs just in time, structured conversations and confirmations through examples, prototypes and documentation. Watch the complete webcast here