IBM Rational DOORS family solutions offer best practices in requirements management and traceability, saving organizations time and money, through improved collaboration with stakeholders to eliminate inaccurate, incomplete, and omitted requirements.
Doors Next Generation is a requirements management application for optimizing requirements communication, collaboration and verification throughout your organization and supply chain. This scalable solution can help you meet business goals by managing project scope and cost. Rational DOORS lets you capture, trace, analyze and manage changes to information while maintaining compliance to regulations and standards.
Top three reasons your organization needs Doors Next Generation
- Reduce development costs by up to 57%
- Accelerate time to market by up to 20%
- Reduce cost of quality by up to 69%
Key Feature's :
Centralized location : Requirements management in a centralized location improves team collaboration, provides access to full editing, configuration, analysis and reporting capabilities through a desktop client. It also supports the Requirements Interchange Format, enabling suppliers and development partners to contribute requirements documents, sections or attributes that can be traced back to central requirements. Records and displays requirements text, graphics, tables, requirements attributes, change bars, traceablity links and more.
Link requirements : Traceability by linking requirements to design items, test plans, test cases and other requirements. Users can concurrently edit separate product and system requirement documents and link entries between documents. Requirement entries can also be linked to models, text specifications, code files, test procedures and documents created with other applications
Scalability : Address changing requirements management needs. Offers an explorer-like hierarchy with multiple levels of folders and projects for simple navigation no matter how large the database grows.
Change management : Integrations to help manage changes to requirements with either a simple, pre-defined change proposal system or a more thorough, customizable change control workflow. It integrates with Rational change management software for requirements change control and for requirements workflow management. It also integrates with other rational solutions, including IBM Rational Quality Manager, IBM Rational Rhapsody, IBM Rational Focal Point and others like HP Quality-Center for visibility of requirements to create test cases for traceability and for status report on coverage of requirements by test cases, and also with Microsoft Team Foundation Server (TFS) to enable Microsoft Visual Studio development teams to create and maintain traceability between requirements in Rational DOORS and TFS Work Items in Visual Studio.
If your organization wants to replace outdated and expensive legacy tools, and needs better control over multiple versions of documents, IBM appreciates the opportunity to discuss REQUIREMENTS with you. If you’d like to see a live demo please click dngdemo,
Would you like to start benefiting by using IBM Rational DOORS Next Generation? Start your free trial today Free Trial
Modified on by VijaySankar
Prof. Lawrence Chung (email@example.com) is in Computer Science at the University of Texas at Dallas. He has been working in System/Requirements Engineering and System/Software Architecture. He was the principal author of the research monograph “Non-Functional Requirements in Software Engineering", and has been involved in developing “RE-Tools” (a multi-notational tool for RE) with Dr. Sam Supakkul, “HOPE” (a smartphone application for people with disabilities) with Dr. Rutvij Mehta, and “Silverlining” (a cloud forecaster) with Tom Hill and many others. He has been a keynote speaker, invited lecturer, co-editor-in-chief for Journal of Innovative Software, editorial board member for Requirements Engineering Journal, editor for ETRI Journal, and program co-chair for international events. He received his Ph.D. in Computer Science in 1993 from University of Toronto.
What are non-functional requirements (NFRs)?
NFRs colloquially have been called “-ilities” and “-ities”, since many words referring to NFRs end with “-ility” (e.g., usability, flexibility, reliability, maintainability) or “-ity” (e.g., security, integrity, simplicity, ubiquity). There are of course many other words that do not end with either “-ility” or “-ity”, such as performance, user-friendliness, power consumption, and esthetics, but still refer to NFRs.
Functional requirements (FRs), in contrast, are about functions, activities, tasks, etc. that may accept some input and produce some output.
Consider, for example, “add” (“+”) on a calculator which adds two numbers given as input and produces another number as output shown on the screen. Now suppose you type “2 + 3 =” now and the calculator shows “5”, but one year from now. In this case, the “add” on the calculator is functionally correct but non-functionally terrible, in particular, concerning performance.
As even in this simple example, a system which fulfills only functional requirements is often times not usable or even not useful.
So, handle NFRs and handle them appropriately. Don’t spend time only on FRs.
The “soft” Characteristics of NFRs and how to deal with them:
NFRs are global, subjective, interacting and graded.
FRs, such as “The calculator shall offer an “add” function”, are local in the sense that they are specific to the particular functions and not applicable to other functions or globally to other systems, such as a “subtract” function or a banking system. However, NFR terms such as “performance” can be applied to many other functions and systems, such as a “subtract” function and a banking system, and also those parts of such a function and a system.
In contrast to FRs, NFRs are subjective in both their definitions and the manner they need to be met – some are more subjective than others. Concerning definitions, for example, usability may mean simplicity and the availability of many help facilities to some people, while the same may mean something different, such as minimal learning curve and fast response. Concerning the manner whereby NFRs are seen satisfactorily met also depends on the (perception of the) user. For example, the keyboard with tiny keys on a smartphone may be usable to young people but not to old people. Also, large keys may be good enough for some people in using a smartphone, but a context-sensitive help may additionally be needed for a smartphone to be considered usable for some other people.
So, clarify the definitions of NFRs. Don’t assume they have unanimously agreeable definitions.
So, operationalize NFRs. Don’t just leave them without how they can be met.
NFRs are also interacting with each other, either synergistically or antagonistically or both. For example, a heavy authentication mechanism, for the purpose of enhanced security, may be hurting usability. If it takes three different passwords, which have to be changed every month and should consist of at least one special character, one digit, one upper case character, one function key, etc., in order to get in the system, the user of the system is unlikely to feel that the system is user-friendly. Hence, a conflict between security and user-friendliness. But a heavy security mechanism may help prevent unauthorized people from entering fake data in the system, hence a synergy between the security and the accuracy of data.
So, identify conflicts among NFRs. Don’t think you can do anything with them individually without any negative consequences.
So, identify synergies among NFRs. This is how we get “the whole becoming bigger than the sum of its parts”.
NFRs are graded, in the sense that they are usually met to different degrees. For example, an “add” function may be seen to be very good, good, bad or very bad, concerning its performance or usability, and different ways to implement the add function may affect the function differently – e.g., fully positively, partially positively, fully negatively, and partially negatively.
So, consider the degree of contributions between NFR-related concepts. Don’t simply think NFR-related concepts affect each other in a binary manner – either a complete satisfaction or dissatisfaction.
In a nutshell, NFRs cannot be defined or met absolutely in a clear-cut sense, i.e., soft.
So, satisfice NFRs. Don’t think NFRs can be satisfied absolutely, whatever the term “absolutely” might mean.
Product- vs. process-oriented approaches:
In science, objective measurements are important. But, are we mature enough to do that in system/software engineering? Also, consider:
“Not everything that can be counted counts, and not everything that counts can be counted.” [Albert Einstein]
According to this wisdom, it seems we need to measure important NFRs and only if we can. For example, you wouldn’t say “I love you 8 love units tonight”. It also seems that we need to shift our emphasis from measuring how well NFRs are met by a system/software artifact to how to handle NFRs during the process of developing the artifact in such a manner that the resulting artifact can be measured well.
So, treat NFRs as (soft)goals to satisfice. Do not repeat developing, scraping, and redeveloping a system, if they do not meet the expected NFRs, until a good system is finally produced.
Rationalize decisions using NFRs:
A (functional) problem may be solvable in many different ways. For example, break entries may be stopped by having a security guard, a housedog, a fortified gate, a home security software system, etc. Similarly, a (functional) goal may be achievable in many different ways also. Which one do we decide to choose and how? We use NFRs as the criteria in making the decision on selecting among the (functional) alternatives. Furthermore, NFRs treated as softgoals naturally lead to the consideration of such alternatives, among which a selection is made.
So, use NFRs as softgoals in exploring alternatives and also as the criteria in selecting among them.
How many NFRs are out there?
There can be many FRs. How about NFRs? If we go through a reasonably comprehensive dictionary and consider how many words can end with “-ility”, “-ity”, “-ness”, etc., this might give a hint. It’s not in the order of tens or even hundreds, but potentially thousands and tens of thousands. Alas, but we have resource limitations – a limited amount of time and money, our memory and reasoning capabilities, etc.
So, prioritize NFRs and their operationalizations throughout the softgoal-oriented process. Don’t simply claim “Our system satisfies all the possible NFRs and absolutely”.
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
Prof. Neil Maiden is Professor of Systems Engineering at City University London. He is and has been a principal and co-investigator on numerous EPSRC- and EU-funded research projects. He has published over 150 peer-reviewed papers in academic journals, conferences and workshops proceedings. He was Program Chair for the 12th IEEE International Conference on Requirements Engineering in Kyoto in 2004, and was Editor of the IEEE Software’s Requirements column from 2005 until earlier this year. He can be reached out at N.A.M.Maiden[at]city.ac.uk
Requirements work is still regularly perceived as stenography, one in which the analyst listens and documents while the stakeholders tell the analyst what they want. This perception is reinforced by the requirements techniques that we use on most projects – the observations of work that we make, the interviews with stakeholders that we hold, and the questionnaires that we distribute to collect data about problems and requirements. These techniques hardly set the pulses racing. Nor do these techniques help us discover stakeholders’ real requirements.
Stakeholders don’t know what they want
One reason for this is that eliciting requirements relies on stakeholders knowing what they want and need. However, most stakeholders do not know what they want or need. They are limited by their perceptions of what is possible – what new business models can offer and new technologies can enable. Your average stakeholder is neither a business visionary nor a technology watcher. So is it surprising that their answers to your interview questions are so, well, banal?
Indeed, many businesses have come to realize that customers are more often rear-view mirrors rather than guides to the future. A new approach is needed – one that empowers your stakeholders. My advice? If you want to discover your stakeholders’ real requirements, encourage the stakeholders to create them.
Make them up.
Why not? After all, when you interview someone, the requirements that they report to you are the results of their own, often limited, creative thinking about a new system – creative thinking that you are capturing at the end of, too late to influence.
In this blog post, I argue it is more effective to get in earlier – for analysts to facilitate creative thinking about requirements as soon as requirements work starts. Think of requirements as the outcomes of creative work – desirable inventions that your stakeholders are guided to come up with. After all, many of your digital solutions should be giving you some form of business advantage, and establishing this advantage starts with requirements – what the solution will give to your business.
Creativity in Requirements Work
Perhaps to the surprise of many in software engineering, creativity is well understood. Many different definitions, models and theories of creativity are available, from domains ranging from social psychology to artificial intelligence. As a software engineer, I was delighted to discover how well the phenomenon has been studied. And how much software engineers could leverage from it.
I like the definition of creativity from Sternberg and Lubart. I consider it prototypical of many of the definitions out there. Creativity is:
“the ability to produce work that is both novel (i.e. original, unexpected) and appropriate (i.e. useful, adaptive concerning task constraints)”
Creative problem solving methods have been available since the 1950s. What is striking about many of these methods is their similarity to software development methods that emerged 25 years later. The CPS method guides people through activities such as problem finding, goal finding and solution acceptance – stages similar to analysis and testing phases of software development. What is different is the focus on creative thinking at each of these stages – creative thinking to maintain a critical advantage in business.
My team at City University London has been leveraging creativity methods and techniques in requirements projects of different types for over a decade, with great results. One approach has been to run creativity workshops – risk-free spaces in which stakeholders can discover and explore ideas often not feasible within more traditional requirements work. A workshop is normally divided into half-day segments in which stakeholders work with different creativity techniques such as reasoning analogically from other domains, removing constraints, and combining visual storyboards. We’ve successful ran such workshops in domains from air traffic control and electric vehicle use to policing.
Another approach is to embed creative thinking into the early stages of agile projects – what we refer to as creativity on a shoestring because of the need to provoke creative thinking in less than an hour. We’ve learned to prioritise epics with more creative potential. We’ve identified creativity techniques that deliver new ideas in less than an hour – techniques such as hall of fame, creativity triggers and combining user stories.
Get More Creative
Much requirements work is creative. We need to adapt what we do to reflect this. Fortunately there are many creativity processes and techniques out there to experiment with. Do try – you will be rewarded.
Modified on by VijaySankar
In this guest blog post, Requirements Engineering Expert, Jeremy Dick continues with his discussion on practical applications of traceability. Read the first two parts here.
What’s really going on when you decompose a requirement?
What’s really going on when you plan V&V against a requirement?
Inspired by recent experience in a large systems engineering project, Part 1 of this blog post series covered the practice of decomposing requirements, which brings about one of the most important traceability relationships in requirements engineering. Part 2 covered the next most important relationship: that between requirements and validation and verification activities.
Part 3 (probably the final part!) presents some other things about V&V we think we have learnt from undertaking a large project: what do you do about new requirements that arise from the V&V you have planned against your main requirements?
Once the need for V&V activities has been established (see Part 2), this will often give rise to new requirements. Broadly speaking, these requirements fall into two types:
Those that affect the design of the product.
Such requirements may constrain the design of the product, and may even add functions. For instance, should there be a need during commissioning to establish that the temperature of a fuel cell does not exceed a certain level, then it may be necessary to design in a means of measuring it.
Those that define the need the build a secondary system.
These requirements are for the construction of test artefacts, such as models and test equipment. In large programs, this test equipment can represent huge projects in themselves – like the construction of a new building to test a new design of jet engine.
Neither of these types of requirement should really be mixed in with the remaining requirements of without recording (through traceability) their origin, because if the choice of V&V changes, then we should be able to identify which parts of the design – or which pieces of test equipment – are present only to make the old V&V possible.
If the need to test a product gives rise to the need to build facilities to carry out that testing, then another development life-cycle is spawned for the purpose. Requirements will be collected for the facility, and further V&V may be required against those requirements. We enter a sort of recursive world of development life-cycles. Some call this “fractal” – the main development spawns smaller developments, which in turn spawn yet smaller ones.
Primary versus Secondary V&V
Secondary V&V arises when V&V activities lead to test artefacts that also need validating or calibrating. For example, from requirements about power delivery, there is a direct need to do some analysis using a model of fluid dynamics – what we call primary V&V. Requirements for the model itself are collected, and the need for validation of the model considered. For example, the model may need calibrating against some similar existing systems. This calibration activity is another form of V&V – what we call secondary V&V.
Requirements lead to V&V activities lead to requirements
As noted above, the need to for V&V leads to design changes or secondary systems, and thus to further requirements. This relationship should be captured; a requirement, rather than having a parent requirement, may in fact have a parent V&V activity. We could say that a requirement “enables” a V&V activity.
In the extreme, a secondary system may impose requirements on the primary product, for instance through the need to interface with it.
An information model
The diagram below illustrates the idea that requirements enable V&V activities
In the diagram, three traceability relationships are shown: “satisfies”, “verifies” and “enables”. There is an example of a primary V&V activity leading to an enabling requirement on the primary system itself – a requirement whose parent (through the “enables” relationship) is a V&V activity.
There are also two examples of secondary systems driven by requirements for primary V&V, and one of those gives rise, in turn, to a tertiary system.
In our current project, we have pushed this model only as far as secondary systems with an “enables” relationship and secondary V&V. An example is the one cited above – a fluid dynamics model that needs itself to be validated through calibration with similar existing systems.
As with all these things, there is probably a law of diminishing returns. How far should you push the requirement to V&V to requirement to V&V to requirement chain? You will have to decide!
A similar model probably exists for other aspects of development – manufacture, for instance. The need to manufacture a product gives rise to the need to construct the factory and plant to do so – a primary development spawning a secondary development. However, the traceability train goes not from requirement to V&V activity to requirement, but rather directly from primary requirement to secondary requirement. This could still be characterized as enablement.
We never build just “the product”. There are always other things that need designing and building that surround the system for various purposes, including testing components, sub-systems, systems and completed products.
What has been presented here is an attempt to get to grips with the traceability required to track the relationships between the product and its secondary (and possibly tertiary) systems.We implemented all this in a Rational DOORS database, with a small amount of customisation to ease the way.
Thank you for reading these blog entries, and please contact me if you are interested in reusing any of this experience and associated Rational DOORS customization.
Read the first two parts here -
What’s really going on when you decompose a requirement?
What’s really going on when you plan V&V against a requirement?
About the author - 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
Modified on by VijaySankar
In this guest blog post, Requirements Engineering Expert, Jeremy Dick continues with his discussion on practical applications of traceability. Read the first part here -
The practical applications of traceability Part 1: What’s really going on when you decompose a requirement?
Inspired by recent experience in a large systems engineering project, Part 1 of this essay covered the practice of decomposing requirements, which brings about one of the most important traceability relationships in requirements engineering. Part 2 here covers the next most important relationship: that between requirements and validation and verification activities. Part 3 will continue the discussion of V&V, and how it itself gives rise to further requirements.
Verification & Validation (V&V)
I don’t care enough about the difference between validation and verification to want to enter into the divisive debate about it here. I am just going to say V&V and be done with it!
Kinds of V&V activity
There are many kinds of V&V activity, and organisations have varied ways of classifying them. In the project I am working on, the classifications are Analysis, Analogy, Inspection, Review, Test and Demonstration.
By their very nature, these types of activity tend to occur at different times of the life-cycle. Analysis, for instance, tends to occur early to predict properties of the proposed design and verify it against requirements. By contrast, demonstration tends to occur late as part of the acceptance tests.
Typically, a whole series of activities will be planned against a single requirement, some early, some late, allowing confidence to accumulate over the life-cycle of the project.
Requests for evidence
Despite the variety of kinds of activity, there is one thing they all have in common: they are requests for evidence of some kind or other. Indeed, I would favour calling V&V activities exactly that: “requests for evidence”.
Intention versus Fulfilment
Those activities that are carried out early in the development process provide evidence that the intended design will meet the requirements – they address design intention. Those activities applied late in the development process collect evidence that what has been built meets the requirements – they address design fulfilment.
Once the need for V&V activities has been established, this will often give rise to new requirements, either on the design of the product itself, or requirements for the construction of test artefacts, such as models and test equipment. (We never build just the product; there are always other things that need designing and building that surround the system for various purposes.)
The management of requirements arising from V&V will be the topic of Part 3.
Requirements decomposition and V&V planning
When planning V&V activities against a parent requirement, you need to take into account the V&V that will be carried out on its child requirements, and their child requirements, and so on.
Take, for instance, the following example where a user requirement is decomposed into a number of system requirements:
The only V&V activity planned against the user requirement is a commissioning test, which will occur late in the life-cycle. However, further V&V activities are defined against the child system requirements. Some of these are design inspections that occur very early, and some are system tests that occur relatively late, but still before commissioning.
There is, of course, a sense in which all these V&V activities provide evidence for the satisfaction of the user requirement, but some of the activities fit more directly against the system requirements. So when planning V&V activities, you need to ask the question: what activities can only be carried out against the parent requirement, and which can be delegated to child requirements? – because those that can be delegated are likely to provide evidence earlier in the life-cycle. And you always want that, if you can get it.
Granularity of V&V results
In the above example, there is one V&V activity that is linked to multiple requirements. In general, the relationship between requirements and V&V activities will be many-to-many.
However, this presents an issue when it comes to collating results of V&V against requirements. The System Test defined above may show positive results for filling, boiling and dispensing, but fail on the time taken to recover (cool down). So it has passed on all requirements except one. In terms of granularity of information, we need to record the result of the V&V activity against each linked requirement.
How is it best to do that? The only place to do that in the information model of the example is on the “verifies” links; there is a link for every requirement-V&V pair.
Another way is shown in the next example:
Here we have separated out the success criteria for each requirement for each test by adding subsidiary objects under the V&V activities (for instance, using the DOORS object hierarchy). Each success criterion has exactly one link to a requirement; a link from a criterion is implicitly a link from the V&V activity. (This link could be made explicit by retaining a link from the activity as well – not shown in the diagram.)
Now we have objects rather than links against which to record the results of the V&V activity (using an attribute of that object). This has the added advantage that it encourages a discipline of identifying precisely what the success criterion is for each requirement against each V&V activity. In addition, the V&V Activity and its list of success criteria can be used as a description/checklist for each particular test.
As results come in, the success/failure status on the success criteria can be rolled up through the “verifies” links to the associated requirements, and then on up through the “satisfies” links to the parent requirements. Both these relationships allow results to be summarised through the eyes of the requirements at every level.
V&V planning steps
These are the process steps we teach for planning V&V against requirements. They are numbered so as to continue from the process steps named in Part 1:
Determine the V&V activities you will need.
Consider what range of evidence you will need to collect to establish that the requirement has been met, and determine the best V&V activities for that. Aim to collect evidence as early as possible in the life-cycle, considering early proof of design intention as well as later design fulfilment. Capture the V&V activities into the database and (if using explicit links) link them to the associated requirements.
Identify the success criteria for each requirement against each V&V activity.
For each requirement/V&V activity pair, determine the success criteria to be applied. Capture each success criterion in a new object under the activity, and link it to the requirement.
Record the results of the V&V activity against each success criterion.
When the V&V activity has been competed, record the success or failure of the activity against each success criterion.
So this is what we now teach those engaged in planning and tracing V&V against requirements, in conjunction with requirements decomposition. It is wrong to assume that people will somehow automatically know how to do this kind of thing. By taking this approach, the V&V plan is well organized, defined at the most appropriate layers, with success criteria defined, and ready for the collection and roll-up of results.
Read the first part here - The practical applications of traceability Part 1: What’s really going on when you decompose a requirement?
About the author - 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
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