| Keith Barett: |
Hello, everyone. This is Keith. First, let me say thanks for attending our session this afternoon. We are going to be talking about reuse-based requirements development and management. A quick look at our agenda. We have one slide for introductions on ProcessExchange and a little bit of background information on myself. We’ll then go through the reuse-based RDM presentation, itself, which is around 13 slides. Should take us about 30 to 35 minutes. We’ll then do a demonstration of both CaliberRM and Req-X or RequirementsExchange and how those two tools work together to facilitate this concept of reused-based requirements development and management. We’ll then end the session with a time for Q&A.
Quick introductions. ProcessExchange is a premier Borland partner. Our primary focus is to help organizations improve the communication between the business and IT. We have a nationwide footprint with expertise specifically in requirements discipline. I am the Director of Professional Services for ProcessExchange. I’ve been in the software development industry about 17 years now. I spent the first 10 years of my experience in corporate world. I worked for AT&T Universal Card Services, Bank of America, and CSX Railroad, had a wide range of job functions across those companies, but all of it in the software development lifecycle, everything from a developer to a project manager to a business analyst to a data modeler and to a manager of a development team. I also managed a testing team and managed a team called Reusable Objects and Components, which is the experience that brings the most insight into this conversation.
After 10 years in the corporate world, I got into the consulting business around ’99. I went to work for Technology Builders, which was the creator of CaliberRM. They were then purchased by StarBase, and now I work with ProcessExchange; but, in those past seven years, I focused pretty specifically on the topic of requirements development & management. In this presentation we’re going to take that experience and couple it with the background I had from the reusable objects and components group, component-based development best practices to see how we can merge those two practices together.
I’m going to jump right in. First slide we’re going to talk about is what is the problem? Why does reuse-based requirements development and management exist? What do we need it for? Poor requirements cause rework. That’s the plain and simple problem we face in the requirements arena. When we author poor requirements, we impact the quality of the software that we build. Rework is a very costly thing. It impacts time, it impacts money, it impacts manpower – all of us have experienced the impact of rework on our budgets and on our timeframes. The lower quality of requirement that we develop in the beginning, the lower the overall quality of the code tends to be, and that indicates a need for rework.
There are several factors that affect this poor requirements quality. I’m only listing two or three that I think are the most critical. First and foremost, requirements are still written in various objective texts. Most of the requirements that we see today are still written in some kind of a document format. More and more are managing those requirements in a tool like CaliberRM and that’s a great step in the right direction, but most of us are authoring tools in Word documents or seeing new tools like DefineIT, which is not covered in this presentation but certainly would be a good tool for elicitation; but we’re doing this texturally. Subjective text means that the person who wrote it may mean one thing, but the person who reads it may interpret it completely different.
Another point to highlight around subjective text is everybody says we should model more. That’s very true. Models do help us gain insight into the requirements; but we need to always need to keep in mind that requirements will probably always stay textural in nature because text is contractual. When we are building a contract or an agreement between the business stakeholder and the technical people, they’re typically looking at text to be more of a contractual thing, especially if we’re building software for a customer externally. Text is very contractual in nature, so we write and alter it in a text mentality, whereas models are conceptual. They help us to understand the concept of what we are doing better, but you’re not going to see contracts containing models in it. The contracts will be textual.
But, it’s really not just a communications issue. It’s a communication between what they meant and what we interpret when we read it. It’s also a translation issue, a different issue. As with any translation from one language to another, be it English to Japanese, a lot depends on the skill of the translator. We’re going from business speak to technology speak; and if the technologist or the analyst isn’t strong in both languages, there may be translation issues which decrease the quality of those requirements as well. That translation issue coupled with the subjective nature of text make for a powerful one-two punch on the issue of quality.
Another problem that affects quality is there that is no standard method of authoring a requirement. You know, we have the unified modeling language (UML) in the modeling realm, so from an architecture and design standpoint, the industry is moving towards the UML, the defacto standard for creating a visualization of the system; and that is very good. But, in the requirements arena, there is no type of standard structured language. There’s no requirements modeling language or RML. We are still writing these subjective text-based type sentences, and that lack of standardization affects us, as well.
I know there may be some people out there thinking well, we are standardizing a good more on use cases, and that is very true. We’re seeing use cases used a lot more when it comes to depicting a user requirement or requirements in general, but we still have to remember that the part of the use cases, the scenario description, the free-imposed and the alternate normal path; and those are still just textural sentences. They are just in a structure, an elicitation technique called use cases. So, even within a scenario, we could still benefit from a more standard method of architecting our textural sentences.
So, these are some of the problems that we are facing in requirements today. This presentation is about how we useful impact that. A couple of more slides to demonstrate the scope of the problem. This is a pretty common slide in a lot of presentations, so I’ll reiterate it quickly. Studies show requirements errors typically show between 40 percent and 60 percent of the total number of errors. Designing code are only about one-third of the errors. We can see by the pie chart that requirements is typically the biggest piece that impacts the quality of the system.
This slide indicates problems with text-based requirements. I like to use the phrase clumping. We see this in Word documents today. We tend to take a bunch of requirements and clump them together into one paragraph. So, we have paragraphs on pages and documents; they are all clumped together. The reason we do that mainly today is because that helps us put in context the story around this requirement, and we write that way. We write in a context that puts all the details together.
But, when we are talking about requirements elicitations that need to go to a technologist for developments, that kind of clumping of information poses significant problems. For example, as we look at this paragraph pulled out of a requirements document, although the paragraph is numbered, there are several questions that are very difficult, if not impossible, to answer when we are dealing with this type of a paragraph. For example, who owns this or who’s responsible for this requirement? What’s the status, priority, or feasibility of this requirement? Has this requirement ever changed? If so, who changed it? When was it changed? What was changed? Why was it changed? Did people get notified that this change occurred? Answering those kinds of questions in a document requires a lot additional manual labor in the document.
Has there been any meaningful discussion around this requirement? If so, where is that information? Was there a validation routine written for this? If so, where is that? Is there some business user justification for this? Where does the requirement trace to or from? What other requirements are related to this requirement? A question that is not even on the list is how many requirements are actually in this paragraph? This paragraph is presented to the technologist, typically as a requirement. But, in reality, there are multiple requirements in there. There may be sentences that depict the aspect of the business and the need of the business. There may be requirements that are from the user standpoint. There may be nonfunctional kind of requirements that talk about performance-related issues, and then, system-level requirements that talk about what the system needs to do from a functional standpoint.
When we use this method of text-based requirements in a document, we’re clumping all this information together; and then the technologist, the business analyst, the technologist, they have to tear it all apart to figure out all the parts and pieces because when you start writing the code, we have to be at that level of detail.
So, how does reuse help with this? Everybody knows the mentality of garbage in, garbage outs. Obviously, reuse around the concept of requirements reduces garbage in-garbage out. If we take the time to create a well-vetted requirement, and we’re going to talk about how to do that without impacting the deadline of a given project, once we’ve created these well-vetted requirements, we’re not putting garbage in. We’re putting a high-quality requirement in that people have agreed to and that it’s been vetted to multiple resources. That improves the quality from the very beginning. Clearly, it helps drive standards and consistency. If we have a team of people focused on these reusable requirements, they can develop those to a given standard; they can be more consistent across the needs of the project.
It drives improved communication; and more importantly, improved translation. Here again, we’re dealing with well-vetted requirements that we’ve had time to iterate through and refine to a given standard. Part of that includes making sure the translation is correct.
Finally, reuse is simply a key at any level, be it code level reuse, modeling level reuse, tests reuse, or requirements reuse to becoming better, faster, and cheaper in the organization. What we want to do in this presentation is talk about using some of the best practices from the component-based development arena around this topic of reuse, of bringing an end to the world of requirements management and requirements development.
So, what can we learn from component-based development? Reuse is first and foremost purposeful. It’s something that needs to be agreed upon at the executive level. It’s very difficult to be a lone ranger in the world of reuse and hope that by simply putting your code or your model tests or requirements on some network folder or in a folder within Caliber that everybody is just going to go find it and start using it.
I’m going to pause here to go back to a piece of my experience because this is where it’s really important. Back in 1997, I was given the opportunity at Bank of America to lead a team of four individuals on an effort to revamp the way our division at the bank, this was a 500-person IT shop, developed software; and we were specifically told to do this based on a reuse-driven component-based development effort. We were given a million dollars; we were given four people counting myself, and we were given one year. Fortunately, our champion was a good visionary who understood that you are not going to change a 500-person organization in a matter of a month or to. He said I’ll give you the million bucks, four people, and one year, and all I want at the end of the year is a plan on how you’re going to make this transition. He understood it would take time to make this transition.
So, we took seven months and we read every book we could find, read every white paper we could find, we interviewed everybody we could find that was further down the component path than we were. We attended every conference we could find on the topic of reuse. We learned a lot about what it meant to institute a component-based development reuse-driven approach in an organization. A lot of the lessons learned and best practices that came from that time is what I’m pulling into this presentation, and one of the most important things we learned is it must be first and foremost purposeful. It needs to be something agreed upon at the executive level that reuse and accomplishing a certain level of reuse is valuable and worth the effort. It needs to be supported across the enterprise, or at least, across a large enough aspect of the company to warrant the effort to get the reuse.
Reuse also requires a plan. The idea of “build it and they will come,” that mentality just won’t work. We interviewed numerous companies. I remember one company, specifically, that had several thousand components in their component library; and when we asked them, well, what percentage of reuse are you getting, they said well, we get six, seven percent. Less than 10 percent reuse was occurring, even though they had thousands of components.
What we learned through that which is the next bullet down is that having a plan and focusing on very specific application families or domains where reuse is likely was important. Now, I’ll talk more to that in just a moment. In this plan it’s never more important than it is now to address all three of these critical areas of people, process, and technology. We didn’t even call it people, process and technology back then. That’s a pretty common phrase nowadays; but I can still go back and look at our presentation from ’97, and it addressed these three areas. We basically said, 1) We need to reskill our people on the techniques of object orientation at that time, and 2) We’ve got to revamp our process; our methodology can no longer be a waterfall lifecycle kind of approach. It’s got to get more iterative and more short-term and focused. The technology that we were using in our software development effort had to change and back in ’97, we started looking around for an integrated suite of applications, much like you see at Borland today. That was nonexistent back at that time, so we were having to build the integrations for the tools that we were using to accomplish the kind of integrations that we’re seeing nowadays. So, the idea of addressing all three prongs – people, process, and technology – these are also very critical to instituting a good reuse initiative.
The other three or four bullets at the bottom were part of the things we learned that came out of our plan. First and foremost was the idea of application family engineering. This comes back to purposeful and a plan. Family engineering simply is the idea that, in most organizations, there are related groups of applications; and within those related groups of applications, the opportunity for reuse is much greater within a family. We went into it thinking well, we’re going to establish enterprise-wide reuse. That was the objective. We quickly learned that the people that were accomplishing what they called enterprise-wide reuse, they hadn’t built one component that was used everywhere; they had defined families or domains of suites, and they were accomplishing a high-level of reuse within a family. If they properly understood all their domains, or they did family engineering across their enterprise and they were experiencing reuse within each family, then they would say we’re experiencing enterprise-wide reuse because each family is experiencing a level of reuse. That made a lot of sense to us; and we utilized that method, as well.
Another method that goes hand-in-hand with that, so once we’ve defined the families and we’ve identified the opportunities for reuse within those families, we actually then developed a “Top 20” list for each family. Then we used these concepts of harvest, refine, and publish and generate, refine, and publish so that we would go into a family with our “Top 20” list of components that would be highly valuable for reuse and we would look to see if they already existed in some form. If so, we would harvest that, we would then refine that to a given standard; and that refinement is key to the reuse process because that is where documentation was done and the quality of the code was examined or, in this case, the quality of a requirement is examined. That’s where everything that needed to be with the item to be reused was put together with this so that when we published it, it was fully supported. Everything was there for the developer to know he had what he needed for it. If we couldn’t find something to start from, then we would just generate it from scratch. Even though we generated it, we still went through this refinement phase to make sure the documentation and everything was with it and then we would publish it.
Through family engineering, harvest, refine and publish, generate refine and publish, we would begin to populate a repository of reusable assets. At the bank, for example, we had identified five families; we identified roughly twenty components per family. That gave us a “Top 100” list; and we set out to begin developing those findings, harvesting or generating those top 100. Those exact concepts directly apply into the world of requirements. As we’re developing requirements for systems, we can look at the families that the systems fall into, we can identify the functionality required within each family, and look for the requirements that benefit that or align to that. We can go through the concepts of harvest, refine, and publish, generate, refine, and publish with the requirements; and we can publish those requirements into a repository as reasonable assets or use that later as a requirement asset.
So, those are some of the lessons learned from my experience in this component disk development arena and how we’ve been applying those. Let’s dig into the requirements arena a little bit more. We’ve defined or refined this concept just a little bit calling it define and refine, reuse and repeat. It’s a constant cycle; it never really ends. Starting with define, right, so we have to define the requirements. We’re using the best practices from the RDM, requirements development and management industry, the component-based development based industry, and OOAD. We’re making sure that we’re writing requirements as objects, which we’re not clumping; we’re not writing paragraphs and pages anymore. We’re writing discrete objects that have relationships to other objects, and that’s how we rebuild the story. We’ll see that on a couple of slides.
Once that initial step of defining the requirement is done than, we talk about refine, where again we’re refining it to the standard. Now, this is an important part to understand. One of the things we’ve learned during the reuse research was, you can’t ask the developer or, in our case, the business analyst who is writing the requirements, they’re interviewing the state coder, and they’re getting the requirements, you can’t ask that business analyst, most of the time, to write that to a corporate standard around reuse because that’s a time-consuming process. They have a project that they’re on, and they have a deadline that they’re trying to meet. So, what we determined and what we instituted back at the bank was that we had a separate set of people, it started small and it grew over time, where their focus, they were the reuse team, they were the ones that did harvest refine and publish and generate refine and publish. We did not burden the project teams with the weight of refining something to the corporate standard because everybody here knows what they would say. I don’t have time for that. You’re affecting my deadline; I don’t have time for that.
To compensate for that, or overcome that, we created a reuse team; that was the team that I managed, Reusable Objects and Components. On that team, they focused on the refinement step. They created the corporate standards; they made sure what they were harvesting or generating was at that standard before it was published into the reuse library. So, what we’re putting into the reuse library are mature standardized assets. Those requirement assets go into that reuse repository. Then, we repeat the cycle over and over again; it gives us consistent and repeatable results as we go through this.
This next slide is a look at the more typical or classic requirements lifecycle that’s in use in many organizations today. This is your typical, it’s an iterative process where we go from product one, we’re working on and; we go through the elicitation stage, and we go through analysis where we are clarifying what we’ve elicitated. Then, we specify those we documented somehow, be it in Caliber or be it in a document - those get written down. We may or may not write some kind of a validation routine for each of those requirements. There are points of iteration through that life cycle. What’s key in this is that typically this lifecycle is performed for each product that we’re developing. So you see, in product two, we basically just completely repeat this lifecycle; and if any level of reuse is occurring, it’s typically a copy and a paste from a document or even within Caliber. It would be a copy and a paste from one project to another of each individual requirement.
Now, we want to talk about how we do this with something called, a requirement asset and we’ll see that in a couple of slides. So, this is kind of a classic approach. Let’s take a look at what it may look like, what it should look like if, we institute a more reuse-based approach. We’re still seeing the phases of elicitation at the top, and then we insert this reuse analysis. This is basically where we ask the question, is the requirement that we’re looking for already in existence in some form or another in the repository? We know that typically nothing is 100 percent reusable, but any portion of any reuse that we can get is a benefit to us. So, we’re going to analyze the reuse repository and verify, does it exit? If so, how close is it to what I need and should I use them? Those are the three items on the left, identify similar requirements, identify the requirement sets, the complete related set of the requirements, and then retrieve that set.
Then, you go back up to detailed elicitation. There will probably be an element of analysis even on the requirement pulled out of the reuse library. To determine at what level it matches my requirements, some form of an analysis on that has got to be done. If we change things, there will be additional specification and validation for it. You’ll also notice the three items out to the right of detailed analysis. There is categorize, capsulate and extract. Those are obviously objects-oriented techniques that we would use to help write a more object-based requirement. That’s critical in this concept of reuse. Then, under detailed specification, we talk about building requirement sets; and that, from a caliber terminology, is building the trace relationships between these requirements so that we understand the relationship of a business requirement to a user requirement.
Once we’re satisfied with the set of requirements that we have, then we have another decision points. Do we need to put anything back in the reuse repository? There may be a step of refinement that you go through to make sure it’s up to the corporate standard for reuse. We either put it back in the publish repository as a new thing or we decide no, it’s similar enough, or nobody else is going to need the changes that I put into it; so, we skip the repository and go straight down to finish my specification for the overall project and validation for the project, and away we go.
Although there are several new additions to that from the prior slide, really we’re only talking about a couple of different decision points.
- Is there something in the repository?
- How much of that can we use?
- If we changed it, should I put it back in the repository as something new?
This next slide is going to give us a better visual representation of what we mean by a reusable requirement asset. We talk a lot about requirements development in management; and the requirement is like a business requirement, which defines the need of the business. The user requirement defines the tasks that the user needs to perform to satisfy the needs of the business; a functional requirement or the task that the system needs to perform to satisfy the user task, which satisfy the needs of the business and so forth and so on. An iterative process is decomposing a typically vague and business-like requirement at the top to various specific and detailed requirements towards the bottom. That entire set of related requirements is the requirement asset, it’s not just the business requirement at the top; it’s the entire tree. It’s the entire structure.
In the clumping method, we would typically see most of this clumped into the paragraph; so that old paragraph may be, in large part, representative of this tree structure. Unfortunately, it’s written in a way that requires the technologist to rip it all apart; and that’s when things get difficult, if we’re altering our requirements and defining our requirements in an object approach and at these categorical levels that business user functional and so forth. Then we’re using trace relationships to connect these to rebuild the story, if we would. Then we’re creating a requirement asset that goes from the business level down to the system levels. No one individual requirement ever stands alone; they all have relationships to other requirements, and it’s only in their relationship context that we have real value to the business. For example, if I only copied over the business requirements from one project to another, I really haven’t achieved any level of reuse.
What I want to be able to do is to pull that business requirement from one project to another and have all of these downstream traces to requirements come with it. Now, I’m reusing a requirement asset, which will bring us to, how the tools of CaliberRM are and RequirementsExchange or Req-X that work together. In this slide, if we look at the upper left-hand corner of the ATM S5000 project, that project would represent our completed projects. It’s done and over and has a mature set of requirements for it. That’s a CaliberRM project, so we have a project in CaliberRM called ATM S5000 and has requirements in it. Directly below it would be the S7000 project, so this is going to be the next generation of projects.
To the far right, is their reuse repository, also housed within Caliber; it’s a project within Caliber. So, we’re populating the reuse repository from other projects like the S5000 or the X4000, which is a legacy-type project. We’re populating the reuse repository from there; and then as new projects come along, we’re querying against that reuse repository for pulling new requirements for well-vetted reusable requirements into the S7000 project. It takes the combination of CaliberRM and RequirementsExchange to successfully do that, which is what we’ll look at when we get to the demonstration.
Last slide for the presentation. Quick recap on the benefits of reuse-based RDM. Certainly, it provides a very repeatable and predictable mechanism for defining, refining and reusing requirements across a product line or development group or an enterprise, keeping in mind that it really addresses the family engineering purposeful and a plan on how we are going to accomplish reuse. Reuse helps to reduce cost inside the market while improving the quality because we’re now using vetted requirement assets. This prevents errors; this helps us to overcome the communication and the translation issues that we talked about in the beginning. But, also it just helps us mature the RDM discipline because now we are beginning to apply best practices from CBD and OOAD that we’ve learned over the years to the RDM process. It allows us to leverage subject matter expertise across an entire product line development group or enterprise, again, across a domain or a family. It provides a mechanism to enforce standards, policies, make new requirements that define these standards and policies more available across the organization.
These are just some of the benefits of using CBD best practices in the requirements arena. So, let’s take a look now at how this works from a product standpoint. Let me pull up CaliberRM first. We’ll give that a second to pull up on everyone’s screen. We’re looking at the ATM S5000 project. This is just a mimicked offer of the typical sample project that comes with Caliber, the automated telemachine project, so we’ve got some business requirements, user requirements, and functional requirements. Within there, we have the withdrawal transactions requirement, which we are looking at now. For those on the call that may not have seen CaliberRM, I’ll give you a quick tour around Caliber. The hierarchy structure is on the left, and it’s broken down into categories.
We have the business requirements, user requirements, and functional requirements. You can add as many requirement types as you would like, you can name them whatever you would like. That way you get to determine how you categorize groups of requirements. Within each grouping or category of requirements, once you enter a requirement or click on a given requirement, you then have a series of tabs over here to your right. These tabs give you all the information that you need to or want to track about a given requirement. So, all those questions that we had a difficult time answering around the text-based requirements are easily answered now as we look at the information across these different sets of tabs. For example on the details tab, we know what the status of this requirement is and what the priority of this requirement is. We know how many revisions this requirement has been through, and we can look at what those revisions are. We know who the owner is; and we see the text that gives us an explanation of this, and we can see that this text is not a paragraph. It’s a very succinct, very object-natured-type requirement that is only talking about the particular business need of withdrawal transaction.
You can also add user requirements. These don’t ship out of the box; we can create them as we need them and add them to customized tabs, which is also what we did for approvals. Then, there’s the responsibilities tab. One of the things we said was, yes the requirement changes. How do the people get notified? That’s what the responsibilities tab is for in Caliber. It enables us to say this person in development is responsible for this requirement; so if this requirement changes, then let them know that. Send them an e-mail. It also allows us to associate reference information to a given requirement. This might be images, it could be text-based information and document, a spreadsheet, it can be a link to a URL for a Web site, any time of reference information related to it.
Then, most importantly for our topic of the day, is the traceability tab. This is where we build those relationships between the business, user, functional, and other requirement types so that we take these individual parts and pieces and rebuild the context of the story that’s so important for helping the businessperson understand and the technologist understand all the parts and pieces required to deliver withdrawal transactions. So, within Caliber, once those trace relations have been built, we can come up here and click on the trace diagram, and we can get a quick picture that shows us what our requirement asset looks like, just as we saw in the slide. There are levels of requirements that decompose from the high-level business requirement down to the lower-level functional requirements. That’s a very important concept. It’s not just withdrawal contractions that we need to move into our new project but it’s also the entire related set of requirements.
We create those trace relationships here. It also has a tab for validation routines, where we can type in a text for a validation routine through integrations with test tools that’s passed over to the testing tools. It also gives us the ability to have discussions around a given requirement, and those discussions are stored in the repository. They’re not spread across e-mail; everything is related to the particular requirement that we’re focused on. Of course, the history tab, which is what tracks all of the information that we’ve done. It’s all the, who, what, when, where and even why, provided the people have entered a comment as to the changes that occurred for this given requirement. It also allows us to create baselines. Baseline enables us to say, out of all the requirements that are in my project, here’s the set of requirements that went into release one or release two. That’s the typical use for baseline.
There are a lot of other features within Caliber that we don’t have time to go into in this presentation, but that’s the quick run through on Caliber. Let me pull up RequirementsExchange, and we can see how these two tools begin to interact. Now, just like with Caliber, there’s a lot of functionality in Req-X that I don’t have time to demonstrate in our conversation today. I’m going to focus specifically on the check in and check outs, which are the two features we would use to facilitate this concept of reuse. Features like import, export, transfer, delete, clone are all valuable features that aid both an administrative person and a general user, but not things that we have time to get into today.
Let me pull back up Caliber and set the stage for us and what we’re going to do. So, this is our S5000 project, which is mature and complete as the requirements end. The S7000 project is about to begin, and we can see that the S7000 project has no requirements in it. It has the categories of business user and functional, but no actual requirements in it. We also have a reuse repository; we can also see that there are no requirements currently in the reuse repository. So, the first thing we’re going to do is identify a couple of requirements out of the S5000 project that are worthy of reuse based on this domain. We’re probably going to reuse withdrawal transactions and most likely to reuse deposit transactions. We want to take those to a requirement, to move them into our reuse repository.
Now, obviously, not being demonstrated here would be the step of refinement. We’re going to assume that they are already refined for this demonstration. Typically in the real world, you would move them into the phase of refinement so that before they would actually go into the new repository and then refine them the way that these tools work. But, it’s important to do this step of refinement to make sure that the quality of the requirement is where it needs to be for a reuse standpoint.
So, we’ve identified that these are the two requirements that we want to reuse, so now I’ll come back to RequirementsExchange or Req-X, and I’m going to do a check in. We’re going to check in requirements from the existing ATM S7000 project. Let me try this again. I had this up for a long time; I was gone ,so let me quickly exit and start Req-X over. As I’m on my own laptop, I might have dropped the connection.
All right, let’s try this again. We’re going to do a check in. There we go. The ATM S5000 project is the project that we’re going to pull the requirements out of. We’re going to put them into the reuse repository. Let me full stream this so we can see it. Next, we’re going to check in the selected items that we’re going to get to pick now. It’s loading the projects, so it’s reading the structure out of CaliberRM and these two are integrated. I’ll highlight a couple of things here. The view that you are seeing on the screen now is a hierarchal view. This is a view that we can’t see within Caliber. If I come down here to the bottom, and I click on physical, this is the view that we’re used to seeing inside of Caliber. It has the business requirements, user requirements, done by requirement-type structure; but for the sake of a requirement asset, what we really want to look at is the hierarchal view. If I click on the hierarchal view, now we can see for example, here’s the deposit transaction and we can see all of the requirements that are required to build the deposit transaction. We get that requirement set view or requirement asset view.
That’s a view that we can’t see within Caliber and one of the additions of Req-X, one of the values there. We’re going to take the deposit transaction and the withdrawal transaction; those are the two that I’m going to check. We’re going to pull them and all of their children requirements, all of their traced to requirements, not just the child requirements, it’s a traced to requirement. Now, we’re going to pull those into our reuse repository, next. So, now it has found 17 items that it’s going to move over from the S5000 project into the reuse repository. Once this is done, I’ll actually go back to Caliber, we’ll pull up the reuse repository, and we’ll see the change that occurred. Okay, I’ll hit finish; now I can minimize Req-X and go back into CaliberRM. We can now switch over to the reuse repository, and now we can see that, indeed, there are requirements populated in the reuse repository. These are all of the requirements that are required for the requirements set of withdrawal and deposit transaction.
We can see that it didn’t only bring over the parent and its children; it also brought over all of these lower level requirements that are necessary to rebuild the tree. So, if I again click on withdrawal transactions and go to the trace diagram, we can see that it’s brought over everything required to rebuild that structure. You can imagine how we would populate the reuse repository by doing this harvest, refine and publish, or generate, refine and publish to put things into the reuse repository. Now, what we will do is we’ll check something out of the repository and move it into our S7000 project. Now we are going to go to check out from the reuse repository, take all selected elements; here again, I can look at this either in the physical view or the hierarchy view. But, when you’re working in the constant reuse form, you’re almost always going to leave it in the hierarchy view.
I can either check the top box, which automatically selects the ones below, or I could choose individually if I wanted to; and by choosing a parent, all of the children are already chosen as well. I’m just going to check the top box because we want to pull both of these into the S7000 project. Say Next. We’re going to put them in the S7000 project and next again; obviously, all the projects that you are seeing on that list are the projects that are in Caliber, it’s integrated with the Caliber repository so it’s reading that information directly from the Caliber repository. Okay, we’ll hit finish. Now, I’ll pull a CaliberRM up again, and we’ll switch to the S7000 project, which we can now see has the two requirements. So, let’s say that we need to make a modification, that the withdrawal transaction requirement in the S7000 project, we’re going to up the cash limit to $500. They’ve obviously been to the movies recently and realized that three hundred bucks won’t get you there for a family of five.
Now, let’s say that we want to add another requirement and say that it’s possible to pull money out of a money market account, instead of just checking and savings account. In Caliber we can simply do a copy, and then we can say paste that as a child requirements, and then we’ll come into the child requirement and rename it to money market. We’ll change the description of that to say money market, so we’ve added a child requirement under withdrawal transactions. Now, if we believe that the added dollar amount and the new money market option are going to be viable for any other application in this family that may utilize withdrawal transactions, we’ll want to put withdrawal transactions back into the reuse repository with these modifications to it. So, we can go back to RequirementsExchange and say now we are going to check back in, but this time we’re going to check in from the S7000 project. We’ll say next, all selected items, now we’re looking at the contents of the S7000.
At this point, we’re really just going to pull back in withdrawal transactions. We’ve already selected everything that’s underneath it. First you can see there’s money market, so it’s definitely pulling all the new information. We’ll say next. Now, the most important step here, we’re going to check this box at the bottom that says, update elements. Now, when we do that it’s simply saying we’re not adding a new requirement to their reuse repository; we’re going to go find an existing requirement and simply update that existing requirement. We’ll say next. Once this is done, we’ll hit finish and go back to Caliber. Now if we go back to the ATM reuse repository, go to our withdrawal transactions, we can see that the dollar amount is now $500. We can see that money market has been added as a child requirement, and there is history indicating these changes have occurred. So, everything is tracked; we can modify an existing requirement back in the reuse repository, republish to that or we can, if we made changes to withdrawal transactions that really made it drastically different, we could have published it back to the reuse repository as a completely different requirement. Either option is possible.
That is really it for the demonstration between CaliberRM and Req-X. Again, there are a lot of features of both products that we’re not taking the time to go into today. Really just wanting to demonstrate how utilizing both Req-X and CaliberRM, we cannot only manage the requirements in Caliber, we can also then facilitate reuse of requirement assets logically related sets of requirements from one project to another. At this time, I’ll turn it back over to our moderator to start any type of Q&A. |
