Early in my career I was fortunate to have a mentor who was very data driven. He believed that data in its purest form would help describe the processes that you might want to implement in a system, but that process analysis alone would not properly define the data and in fact, might very well define it improperly due to the usual insular aspect of looking at some processes and not all, of necessity given scope and budgets.
Furthermore, since we all know there is a many-to-many relationship between Courses and Students, we are probably missing an Entity Type - one that is fairly obvious anyway - something called "Course Registrations" which becomes a one-to-many relationship with each "Kernel" entity type, resolving the many-to-many relationship by adding the "Associative" entity type. And we won't even get into the difference between registrations and transcripts, whether things like marks even belong in this model, etc.
Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Data-Driven Requirements Gathering
Categories:
Requirements Management,
traceability,
scope,
Business Analysis,
Data Models,
Complexity
Categories: Requirements Management, traceability, scope, Business Analysis, Data Models, Complexity
|
When I think about this at a high level in terms of typical data entities and processes, I have to believe that the metrics would support such a conclusion. If we look at any particular organization, the number of processes operating on the same, similar or related data will be very high, yet the number of entity types the organization deals with will be very low in comparison. So let's look at a very simple example, a basic course registration system. Here are the entity types we'll deal with:
Here are some business rules around the data:
From this simple example, I conclude that we have at least the following potential processes:
.... and so on ... and so on... and so on... All of the processes I listed come directly from the two entities, student and course, along with the attributes each has and the relationships they have, one with the other. I am sure with a little extra thought, the list could be doubled. I am also sure that some of the processes listed have nothing to do with a student registration system, and more to do with other systems, and so could serve to put some rope around both the data (and its attributes) and the processes to be able to plan multiple projects as part of a program.
I obviously invented a lot of the processes I listed, and they would likely be very different if I actually had stakeholders to help me along (or would they?). It may reveal new business rules, such as those student registration privacy or restrictions on instructor performance data, or the absence of processes, such as being able to label other students who are your friends, and seeing which courses they have registered for. A very simple example, of course, but from two entities (which eventually became three), I was able to derive at least 18 processes (some actually have multiple processes per line), and I did that as quickly as I could type. Confirmation with the stakeholder would take much longer, of course. Trying to create a long list of processes and then deriving the data from them, rather than letting the data drive the derivation of processes, is, I feel, much more complex, time consuming and subject to errors and omissions. What do you think? Are you process driven, or data driven? Were you one and became another at some point in time? Before you answer, remember the CRUD (or CUDDL) I mentioned in a previous post. Don't know what that is? Look up "Of CRUDs and CUDDLs" :)
|
Posted on: November 04, 2015 11:49 AM
| Permalink |
Comments (10)
When do requirements need to be completed?
| People often ponder whether requirements for an IT project should already be in place before a project begins, whether they should be detailed at the front end of a project, or whether they should be refined as the project progresses. The answer is not simple, and has a lot to do with the sort of project you are running. We would all likely agree that no project can even be chartered without some level of requirements being in place - high level business requirements at the very least. But it is a rare project that will kick off to the resounding thump of a multi-hundred page business requirements document. Most waterfall-type projects have the creation of the BRD as an early step in the project. Most Agile projects will have high level requirements, often in the form of user stories. And then there is everything in between. But there's the rub. What apporach and methods are being used on your project? Is it waterfall? Is it one of the Agile approaches? Can requirements change while the project is in motion? Might such changes alter the direction of the project? I would hypothesize that requirements can and do change on any project, regardless of the project methods being used. Remember the old requiremernts freeze? "You must sign here, and we will build what you have asked for. No changes wiil be permitted from now until project end." Seems almost hilarious now, doesn't it? The only freeze that would really be in effect is the one that freezes you out of any more work with that client. So - still we are left with question, "When do requirements need to be completed?". The question itself might be a tad banal. Before we design, before we build, before we test... requirements must be clear. Do we need a 50 pound signed off document early on? Maybe... if we are designing and building software to run a space shuttle. But do we need it if we are only configuring an ERP package? Or designing a web site? Or might we need only story elaboration a bit at a time when we have a fully engaged and knowledgeable Product Owner? As with most questions in this field the "It depends." answer pops to mind. It depends on so many factors, including contract types, that the answer will shift like the sand dunes on the Sahara. It's getting cold in here. Must be those frozen requirements. |
Posted on: May 22, 2015 11:42 AM
| Permalink |
Comments (9)
Of CRUDs and CUDDLs...
| Back early on in my career as I moved from a programming role to an analyst role, I was fortunate to be funded for training by the utility company I worked for at the time. The training was conducted by Tom deMarco of Ed Yourdon and Associates, and had to do with analytical techniques, dubbed structured analysis - mainly data flow diagramming (DFDs), and data structure diagrams (DSDs). DSDs fell by the wayside, but DFDs served me well over the years. The basic premise was to model a clien'ts environment using sources, data flows, processes, data stores and sinks. These fanciful terms could be used in diagrammatic form to describe the "current physical" and "current logical" environments and then the "future logical" and "future physical" environements. There were many rules and methods one could employ, such as "structured english" to describe processes, and ensuring that a process transformed the input data flow into the output data flow. We learned that if the output data flow was the same as the input data flow, well then, there was no process at all, was there? And if there was something in the output data flow that was not input to the process, there was something awry with the process. Data flows represented data in motion and data stores represented data at rest. With all that flowing going on wasn't it thoughtful of Ed and Tom to give data a break now and then? At the time, I was a young buck looking for the silver analysis bullet to help advance by career by doing a stellar job, and I thought this was the ultimate way to model current state and describe future requirements. It worked very well over the years, and still does, for that matter, although I have to admit I may have become somewhat less rigid about applying Ed and Tom's rules. After a few years with the utility company, I moved half way across the country to join an oil and gas company. I learned about data analysis from a company called LBMS, which if memory serves, stood for Learmonth Burchett Management Systems, a company from London, England. What they were doing in Houston is anyone's guess. Like the process modeling I learned about from Ed and Tom, in data there were both logical and physical aspects. I came to the conclusion that data at rest was actually far more important than data in motion, and became somewhat of a data zealot, tossing aside my previous process modelling soapbox for a new data modelling podium, waxing eloquently (well, maybe just waxing) about logical data models, entities, attributes, relationships and obscure things like fourth normal form. A slightly older buck at that time, I moved into the realm of data management, database administration and data-driven applications development, even helping to develop a tool that would generate code from a data dictionary based on data entity types and their attributes. We called it the prototype system, and it was truly impressive (if I may say so myself), generating a menu structure with "CRUDs" for each entity type (Create, Read, Update, Delete). We didn't get as far as generating reporting modules for each relationship between entities in the data model, but we could have. A colleague I worked with subsequently insisted on calling these generated modules CUDDLs, not only because we added list functionality (hence the L) allowing the display all instances of the Entity, sorted in multiple ways as desired by the user, but also because CUDDL sounds a lot nicer than CRUD. I have to agree. Go ahead - pronounce both and decide for yourself. I have seen and used many more modelling techniques over the years including use cases, user stories, affinity diagrams, and so on. I am glad to see a mix of both the old and new techniques in current materials, such as PMI's newly minted Business Analysis for Practitioners: A Practice Guide, which you can still download for free at pmi.org. So what is the message? A guess there are a few. Realize that many modelling techniques are necessary to do a good job in your analysis role - so learn many of them. If you must be a zealot about something, choose modelling. Don't choose a specific hill upon which to die. It's not a war, and there are many hills worth saving. Now, does anyone know what you call a ... shall we say ... seasoned buck? |
Posted on: March 20, 2015 03:47 PM
| Permalink |
Comments (3)
Quality in Requirements - Get It Right The First Time
| Ever wonder about that ephemeral word quality while elicting and documenting requirements on your projects? How can you plan for quality and reduce re-work, especially if you are an Information Technology professional whose products cannot even be seen or maybe even conceptualized until they have already been produced? Of course, you will use illictation methods and models to show your clients what you understand to be their requirements, but what about the production of the deliverables, the fruits of your labour? Well, the old adage "when you fail to plan, you plan to fail" applies here just as it does in any of the ten knowledge areas PMI defines for all projects. Yes - believe it or not - quality doesn't just happen. And quality does not equal perfect, otherwise every project would go on forever, just like that children's song "This is the song that never ends." :) So - how can you plan for quality? Well, for a start, you can tell your project sponsor and stakeholders how you plan to meet the requirements they have laid out for you, starting with identifying the deliverables you will produce as defined when you broke the work down into an understandable structure (look up "work breakdown structure".) Engage your team and stakeholders in describing each deliverable before you start producing it. Identify who is going to produce each (probably team members) and who is going to review and sign off on each (probably clients). Seek their input, agreement and sign off of a "deliverable expectation document". Use this subsequently when the deliverable has been produced and the review is occurring. Assure quality - build it right the first time, but control quality too - check that it was, indeed, built right the first time. How do you assure quality? Standards, best practices, templates, examples, expert advice, lessons learned, past experiences, involving the right people, measuring - all these and more go into assuring quality. How do you control quality? Review by subject matter experts, carefully planned testing, dreaded re-work (made unnecessary, of course, by your excellent quality assurance processes). Remember - you can't test quality in, so pay a great deal of attention to quality planning and assurance. There... now that is simple, isn't it? Can you get it right the first time? Well - probably not always, but it is sure worth the try, don't you think? Now, if I could just get the cursed song out of my head... this is the song that never ends... it just goes on and on my friends... some people started ... help! |
Posted on: February 20, 2015 09:17 AM
| Permalink |
Comments (0)
The Twelve Days of My Project
|
On the first day of my project
On the second day of my project
On the third day of my project
On the fourth day of my project
On the fifth day of my project my clients sent to me:
On the sixth day of my project my clients sent to me:
On the seventh day of my project my clients sent to me:
On the eighth day of my project my clients sent to me:
On the Ninth day of my project my clients sent to me: 9 form revisits 8 stories added 7 new sub-systems 6 scope additions 5 new stories 4 new features 3 epics 2 use cases And requirements verbally On the tenth day of my project my clients sent to me:
On the eleventh day of my project my clients sent to me: 11 interfaces
On the twelfth day of my project And all's well that ends well! Happy Holidays! |
Posted on: December 22, 2014 02:45 PM
| Permalink |
Comments (9)