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
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.
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 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
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
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.
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.