Corrections to LinkedIn's Course, Business Analysis Fundamentals

LinkedIn's inLearning course (apparently they got it from Linda.com), Business Analysis Fundamentals, provides plenty of useable information. However, I was frustrated with a number of points. The most damaging were the course's confusion about Validation, Verification, Traceability, and Stakeholders.

• You validate requirements by confirming that they have authority, are necessary, and meet standards for quality. Validation looks upward.
  
  
• You verify that requirements are met either by lower-level requirements or by the product. Verification looks downward. Methods include Inspection, Analysis, Test, and Demonstration.
  
  
• The course reversed these distinctions and identified only Test as a method of verification.
  
  
• Traceability links each requirement to directly-related higher- and lower-level requirements. Traceability enables validating requirements' authority and verifying their satisfaction.
  
  
• The course's discussion of traceability focused on metadata about requirements' sources. While such information is useful, it is a very minor part of traceability.
  
  
• Stakeholders include everybody who "has a stake in" the project.  The course focused on external stakeholders. It should have included the project team and other internal relationships such as other projects.
  
  
• The course's definition of Functional Requirements includes activities that the project needs to do to deliver the product. It should also have included what the product does and how well it does it.
  
  
• Since the course only half understands what constitutes functional requirements, it classifies Performance among nonfunctional requirements. Project performance is nonfunctional, but product performance is functional.
  
  
• The course treats Transitional Requirements as a separate category. If the project performs a service, transitional requirements can be Functional requirements; and if the project creates a product, they are usually nonfunctional.
  
  
• The T in SMART stands for Time-bound. The course replaces this with Traceable. The substitution is a good one, but it is nonstandard, and it requires that you include temporal requirements in Specific.

As I said, the course provided plenty of actionable content. I would be proud to work with the instructor, and I would learn a lot more from him that he would learn from me. However, we'd have to work out some issues, first.

The Black Hole of the Agile World: Systems Thinking

Agile fanatics (excuse me: practitioners) love to do things in tiny increments.

That's OK for products where bite-sized deliveries have value, but it's fantasyland for many real-world projects.

Take, for example, the design of a new car. Sure, you can break the car into systems -- chassis, body, safety package, motor, and so on. Waterfall does that, too, but let's consider the airflow over the body. The airflow is affected by the whole assembly. Every part affects the whole. You can't just design a fender in isolation and say, "Looky, looky, I've delivered value!" No, you've delivered an irrelevant piece of scrap.

In any course on Business Analysis, the importance of a unit on Systems Thinking cannot be overemphasized because the Agile world has completely forgotten its value. 

Before the 1990's, there was a role called Systems Engineer.

That title is still around, but the job is not. At least, the job has become a rare grain of wheat a vast field of tares.

A Systems Engineer had many skills of a project manager, a BA, a Systems Thinker, and a cross-disciplinary engineer, all rolled into one.

Along come companies such as Microsoft and Cisco, dropping the qualifying word from titles such as Network Systems Engineer, Software Systems Engineer, and Server Systems Engineer. Suddenly, every engineer, analyst, and administrator is a Systems Engineer. I wish I had a paycheck for every time a recruiter has contacted me with a so-called Systems Engineer job that turned out to be for an IT admin or a software coder.

True Systems Engineering jobs have become needles in a field of haystacks, and systems thinking has almost been forgotten.

Thousands of Systems Engineers lost their jobs due to decimation of the US Defense sector in 2009. (I proud of myself for not pointing out the predictable political element of that.) They still find three strikes against them:

1. Transitioning to a different job category such as Project Management or Business Analysis
2. Getting a foot in the door of a different industry (other than fast food)
3. Living in a job market where all the growth is in part-time service jobs and has gone to low-skilled workers

Hiring managers would do well to consider bringing in experienced cross-disciplinary, systems thinkers. It would not take much training to bring them up to speed in new roles such as PM or BA.

Have you ever thought of a project as a system of people, or a product as a system of technologies? Systems Engineers do that instinctively, and such integrated systems thinking could prevent a lot of headaches for maturing companies.

Now, if you'll pardon me; I need to clean up a spill in aisle five.

Training the Software Requirements Engineer

What are different type of training required for a Software Requirement Engineer?

The correct answer is, it depends. Software requirements training should fit with the type of project management used by your organization.

One type of training you don't need

Many people think a software requirements engineer should thoroughly understand programming and software engineering. Obviously, you should know something about the software engineering discipline, but knowing too much can destroy your ability to write good requirements. This happens for two reasons.

First, good requirements should ignore the technology (such as which platform or language is used). This is because requirements should not dictate the solution; they should only define the problem to be solved. Devoting too much study to the technology will bias a requirements analyst toward particular solutions. This makes consideration of alternate solutions more difficult for the design engineers.

Second, requirements elicitation is an art as much as a discipline. Managing stakeholders, conducting meetings, choosing elicitation methods, and choosing methods for representing information require strong skills in psychology and communication. Putting all your energy into learning programming languages and tricks will cost you on the human side. It would be as great a mistake as putting all your energy into market research. You need to know enough about programming to win the respect of the designers and to communicate with them, but your job is to build a bridge between the customer and the designer.

What should I wear? Well... where are you going?

Organizations that work with large systems that integrate multiple technologies tend to follow traditional Project Management and Systems Engineering methods. They use some variation of the Waterfall model, such as the V model.

For a high-level understanding of Systems Engineering requirements methods, I recommend starting with INCOSE's (International Council on Systems Engineering) Systems Engineering Body of Knowledge (SEBOK) and using the SEBOK as a guide to subjects for study. Also consider studying Model-Based Systems Engineering, one subset of traditional methods, and SysML, the modeling language used for MBSE.

Organizations that work primarily with software tend to follow Agile project management methods. In Agile environments, requirements engineers tend to go by the title Business Analyst. I recommend starting with the IIBA's (International Institute for Business Analysis) Business Analysis Body of Knowledge (BABOK) and using the BABOK as a guide to subjects for study.

Agile is a set of principles and not an actual method. I have asked for a recommendation for a book that describes the different methods (such as Scrum and Kanban) but have been told no such book exists; for each Agile method, you need to find a different book.

The requirements methods differ considerably between traditional and Agile. Traditional methods nail down requirements and then negotiate schedule and cost. Agile nails down schedule and cost and then negotiates, prioritizes, re-prioritizes, and drops requirements.

The two methods do share some of the same tools. I suggest studying Unified Modeling Language (UML). UML is not a language, but a set of graphical methods for defining requirements. The most commonly recommended book on software requirements is Software Requirements, 3rd edition, by Karl E Wiegers and Joy Beatty.