Not Everyone Sees the Value of Software Requirements Services Let’s talk about software requirements services. I travel a lot for work. Travel, despite the implications of movement, actually involves a
In an earlier blog post, I suggested that Machine Learning might be an interesting alternative to rigorous facilitation for the discovery of business rules. Today I’d like to talk about
What? In 1999, Buckingham and Coffman authored First, Break All the Rules. They used Gallop data from manager interviews to identify how good managers drive employee satisfaction. Internally at ArgonDigital, we
I recently had the opportunity to work with a company that had a long sales and construction process. In their industry it generally took three months to complete the process,
Very nearly every project that we work on as analysts has business rules. Business rules aren’t functional requirements – they are modifiers to functional requirements. For example, we may have
When we work with IT teams, one area that we emphasize is the importance of understanding the business value of what we’re working on, whether that is at the feature,
It’s been argued in programming communities that all programming languages can ultimately be abstracted back to LISP. As a software developer, you may not care that we can ultimately abstract
ArgonDigital is an interesting place to work. One of the things I love about it is that our service delivery department has people who come from a huge range of
Ok. I said it. The dreaded “D-word”. Design. We’re not supposed to do that. Let the designers do the designing, and let the business analysts define the requirements. Actually, I’m
When we train people in the use of different requirements models, we typically mention three models as being distinct by virtue of the fact that you can know they are complete:
We’ve been having some internal debate about the appropriate use of swimlane diagrams. Everyone agrees that swimlane diagrams are a helpful model. They allow you to create a process flow that
We use a well established model for looking at the relationship between business requirements and the software requirements that are derived from them. Using the Requirements Object Model (ROM), we
Don’t miss out on this opportunity
and request a conversation today!
