Continuing on from Use Cases in PRPC – Part 2, the following tables will give Pega Business Architects an idea of how to use PRPC’s “Use Case Rule” to capture details about your Software Use Case.
|
In Part 1, we took a look at Pega’s definition of a Use Case and what the Application Profile Wizard allows Pega Business Architects to capture. In Part 2, we shall now take a look at four different types of Use Case and how they relate to PRPC. Business Use Case PRPC Constraints on BUCs Software (System) Use Case The PDN refers to SUCs as “Comprehensive” use cases, but does not give any guidance on whether or how to model them. See Use Cases in PRPC – Part 3. Atomic Use Case PRPC Constraints on SUCs and AUCs Technical Use Case PRPC Constraints on TUCs Use Case Linking The SUC author analyst can note any AUCs which sit under the SUC (forward linking). SUCs can have more than one AUC because AUCs are individual steps within a SUC. Each AUC can relate to more than one SUC, which indicates re-use. The TUC author can note any AUC or SUC the TUC relates to (backward linking). Each TUC should relate to a single SUC or TUC. Not all AUCs will require a TUC. Use Case Categorisation
Related posts:
I am willing to bet that in the business world, at least, everyone puts on their CV (resumé) that they have excellent communication skills. They can’t all be right.
Care about your audience, not just about your message. Kind regards, Declan Chellar I am frequently contacted by recruitment agents who claim to have read my profile. Today one contacted me with a job which the agent claimed matched my profile. The following are the mandatory skills. I have crossed out the ones I don’t have:
A cursory glance at my online profile would rule me out. I have now ruled out ever dealing with that recruitment agency (among others). I work with some very conscientious recruitment agents who go to great lengths to ensure that I am the right consultant for their client, but if my inbox is anything to go by, most of them are lazy, keyword-searchers. Chances are your company is using such an agency. I can recommend some good agents if you are interested. Related posts: On so many projects, I have seen software developers thrown into meetings with the business SMEs with the task of understanding the “requirements”. On some occasions I have been delighted to see developers with the ability and techniques that truly enable them to think in terms of business needs. Mostly, however, I have witnessed techies simply documenting the problem they are presented with and instead of trying to understand that problem, they focus on coming up with a solution (often using only convergent thinking to come up with a single solution). The underlying causes of this are a general ignorance among managers and technical people of what skills are involved in business analysis, and a failure to give those skills to people who have to perform BA tasks. It takes more than a familiarity with MS Word and Visio and the ability to speak in whole sentences. This is why so many software projects fail to satisfy their customer entirely, because the people providing the solutions never really understand what the customer needed in the first place. Sometimes the customers themselves don’t even understand what they need! They only know what they want (hence the emphasis in this business on “requirements”). If you don’t see the difference, then you do not understand business analysis. Software development requires a different mindset to business analysis. It is a mindset that explores solutions to identified problems or needs. It is a prescriptive mindset. It is a mindset that identifies the solution as a hammer when it perceives the problem to be a nail. It does not ask whether the nail is actually the real problem. After all, the customer might have described the problem as a nail, when it is in fact a screw. The analysis mindset is investigative and descriptive. It explores the business need, seeking to understand its true nature and how it affects the business. This mindset challenges what the customer says. Is it really a nail? What type of nail is it? What material is it made of? What size is it? What material does it have to be driven into? How does the business benefit from having this nail driven into that material? Note that I have used the impersonal terms “software development” and “business analysis”, rather than “software developers” and “business analysts”. This is because both mindsets can exist in a single software developer and both can exist in an individual business analyst. They rarely do, in my experience. However, if I were to build my ideal three-person software development team, it would consist of:
Full systems lifecycle development experience is invaluable to any team member on a software development project. Projects which take an agile approach to software development ameliorate this problem. However, the problem is not eliminated unless agility is support by two other factors:
Takeaways:
Kind regards, Declan Chellar There is a perception that Pegasystems PRPC can be used to create BPMN-compliant process models. However, I consider this perception to be incorrect. This slide show takes you through my reasoning, but I can sum up my conclusion with a golf analogy: No matter how good your 3-iron is, you can’t turn it into an 8-iron by scratching on the number. Don’t get me wrong: the PRPC Flow Rule is an excellent tool (a really good 3-iron, if you will) – but there is more to BPMN than the shapes themselves. Note: the Pega Developers Network does not claim that you can model BPMN-compliant models within PRPC, but some Pega Business Architects have made that inference.
Kind regards, Declan Chellar Related posts: Many analysts have a grounding in grounding in one main area of business analysis, such as process modelling. However, a company’s business architecture cannot stand on a single leg. In fact, three legs are required:
I have seen many software development projects where none of these is in place before the project starts, with disastrous consequences. In some cases, only the process models are driven out and while data requirements and individual business rules are documented, they are not modelled. If process is the highway network and data are the cargo to be moved around that highway, then decisions are the engines that move the data around the highway. All three models should be mature (though not necessarily perfect or immutable) before software projects start. Where companies pay any attention to these models at all, of the three they tend to focus on process modelling. Businesses tend to skip over logical data modelling, often because they are not even aware of such a thing or its benefits (I explore this further here and here). However, the one which seems to suffer the most from being ignored is decision modelling. Business decisions are relegated to being documented late in the day as requirements of a specific software system and often in pseudo-code, rather than natural language. The result is that they are often not re-usable across areas of the business (or even across software implementations in the same area of business) and they are not easily manageable by the business as a single asset at the enterprise level (despite what your process-implementation or rules-engine software vendor might tell you). Business decisions are what drive businesses, yet in software development, they seemed to be treated as the poor cousin from out of town. While it is good to be an expert in only one of these three key business models, as a business analyst you need to be competent in all of them. After all, who wants to sit on a stool that has fewer than three legs? Kind regards, Declan Chellar
If you are a business process analyst, you need to print out the image above and stick it somewhere visibile whenever you are building process models. Process analysts often forget that business processes (certainly in the context of software development) work by moving data around an organisation. If the business has not modelled its data, point out that it should. If you are unfamiliar with its data model, ask about it. If you don’t know the basics of data modelling, learn. Process names typically evoke business entities: “Take Order”, “Add Customer”, “Update Account”. You cannot be sure everyone involved in analysis the process is talking about the same things unless these entities are defined in a data model and that definition is understood by all. Moreover, you cannot accurately define data requirements if they are not based on a robust data model. Yet I continue to be surprised at the number of companies that do not have a model of their business data. Now read these earlier posts: Kind regards, Declan Chellar In a previous post I lamented the limited list of default requirement types that PRPC provides. However, there is a way to extend that list. A few months ago I was working as a Pega Business Architect and I asked a Pega Certified Lead Systems Architect (a former Pega employee, in fact) if he knew a way around this limitation. He was not aware of one, but promised to look into it and after some experimentation, his solution was as follows:
Any time you add a new field value this way, the value is added to the “Category” drop-down of any new or existing Requirement Rules. The LSA explained to me that steps 1 and 2 above effectively create a requirements framework, which you can re-use across applications by including the [Organisation]-AppDefinition ruleset in each application. More recently, in preparation for Pega’s Certified Methodology Black Belt exam, I discovered in a training manual that Pega had already documented a similar approach (although it does not seem to be in the PDN). Pega’s approach is essentially the same as above, except it leaves out the first two steps. In other words, you would have to add your new requirement types to each application separately. If you do try either approach, please do send some feedback here via the comments. Kind regards, Declan Chellar
Scott Sehlhorst (@sehlhorst) has written an excellent article titled Requirements vs Design – Which is Which and Why? Some of my own thoughts are in this post, but read Scott’s article first to get the context. Scott seems to gather the problems a business sees with its current model (e.g., inefficient practices, outdated rules, failure to comply with the law) and any opportunities which have arisen (e.g., because of changes in the law, new markets opening, the availability of new technology) and to which the business would like to adapt under the heading “market requirements”. I would be uncomfortable calling these “requirements” because I see them instead as observations of the current state of affairs. But all I disagree with here is the label. He goes on to talk about analysing the problems and opportunities in order to produce a set of goals. I would refer to such goals as “business needs” which have to be satisfied in order to mitigate the problems and take advantage of the opportunities. Scott would see such goals being documented within a Product Requirements Document, whereas I do not see business needs as product requirements, since not all business needs are going to be satisfied by building a particular product. Some will be satisfied simply by changing the approach to staffing or by modifying a manual process. I do agree with him that goals (business needs) are the outcome of what he calls “ideation” and that they need to be documented. Again, we don’t seem to be at odds with regard to the underlying concepts, just the terminology and documentation. I would document the problem/opportunity statements, the analysis of each and its consequent business goal all together in the same place. Subsequent to that, I would expect to see a “future state” model of the business which reflects how the business needs to change in order to attain those goals. Only if part of that future state needed new or enhanced software would we start talking about product requirements. I disagree that “design constraints” are requirements. However, that could also be down to our different use of terminology. Scott seems to use the term to refer to constraints imposed by the business, e.g., product look-and-feel, performance, accessibility. I refer to such constraints as “non-functional requirements”. NFRs are always provided by the business and as such are business requirements. In my head, a design constraint is imposed by the solution design (a term also used by Scott and I happen to use that term in the same way) or by the chosen technology (e.g., a configurable BPM tool). The following are examples of what I would consider design constraints:
If by “design constraints”, Scott means what I call NFRs, then I agree that his design constraints are requirements. However, what I call design constraints are usually not requirements, although they can be. The last example I provided above could be a design constraint imposed by the business because they want to get maximum ROI out of the tool they have licensed by avoiding customised GUIs. [Edit: In his comment below, Scott points out that NFRs, such as coding standards, could be imposed by the development team, and I agree. It is merely my preference to label constraints coming from the business side as NFRs and those coming from the technical side as design constraints. In the end, Scott and I are talking about the same thing.] The solution design can also generate technical requirements. TRs are not of interest to the business but they are not simply design constraints. A TR means that some functionality must be built in order to realise the solution design, but the business has not requested it. Such functionality is invisible to the business. I think it is essential for product requirements, solution design and choice of technology all to be traceable back to business needs. However, business representatives often provide product requirements which are at odds with the stated business needs or which are not traceable back to any stated business needs. Many times I have challenged requirements, asking “What is the business need here?”, only to be met with blank expressions. In some cases, there are no documented business needs. I have often found that requirements analysts fail to actually analyse the product requirements and merely document them without understanding the underlying needs. Those who procure a particular technology (e.g., a customisable workflow tool), often do so based on a slick sales pitch, rather than its ability to realise the business vision. Programmers, too, often fail by simply building what was required, never questioning whether the solution really satisfies the needs of the business, even if it fulfills the product requirements. Thus, for me, business needs have primacy over requirements (see the image below). The latter should always be sub-ordinate to the former (as should the solution design and the chosen technology) and good analysts will think and work accordingly. Unfortunately, a lot of analysts choose to behave merely as requirements stenographers. [Edit: Scott knows this, of course, so this paragraph is dedicated to you junior analysts reading this post: Think! Challenge! Understand! Don’t merely take notes.]  Everything should focus on supporting business needs I assume you have read Scott’s article by now, but I suggest you read it a few times. I prefer the terminology that I use (Well, I would, wouldn’t I?), but believe I agree with Scott’s underlying principles. If I have misunderstood any aspect of Scott’s article, I’m sure he will set me straight and I will update this post accordingly. [Edit: Which I have!] Kind regards, Declan Chellar Related posts: |
