Need a reference for basic business terms and processes
May 5, 2020 11:02 AM   Subscribe

"Conceptual requirements". "Business case". "Business requirements document". "Business requirements specification". "TDD". I left academia for industry and am utterly lost with regards to business terms and processes. I would like some kind of business reference or glossary or crash course. Can you help?

This question is vague because I do not know what I'm talking about. My job is not in the business side of things, but obviously the context is there so I would like a greater understanding of how these things work. Examples of questions:
  • What's the difference between BRDs and BRSs, and where do they fit in project development?
  • What's a business use case?
  • What are the formal steps in project development and the common outputs expected along the way?
  • Definitions and examples of all those terms mentioned in the question opening
  • What's a scrum leader? How is that different from project manager?
  • . . . and so on
Those are just off the top of my head. If you are able to answer them specifically that would be awesome, but a lot more pop up in the course of my work so it would be most helpful if there was some way to read about common business steps, outputs, definitions, that sort of thing so I understand what's going on. Examples would be exceptionally helpful. I get the feeling there is this common language and understanding of business that I just never learned.
posted by anonymous to Work & Money (9 answers total)
 
Response by poster: More question examples:
  • What is a risk? How do you identify low versus high risks?
  • What are business questions?
  • What are business requirements and how are they determined?

posted by Anonymous at 11:09 AM on May 5, 2020


I think it might be helpful to know what industry you work in, and in which region of the country/world. Different industries in different locations have different terminology.
posted by greta simone at 12:02 PM on May 5, 2020


Response by poster: I'm in the USA and I work in telecommunications.
posted by Anonymous at 12:33 PM on May 5, 2020


For the 50,000 foot view of the framework that these types of terms fit into, you could do worse than the Wikipedia article on "Systems Development Life Cycle." As for the glossary, these two FDA documents might cover some of what you're looking for, even though they are ancient.

Going deeper starts to get a bit tricky. Even though they sound generic, the kinds of terms you're asking about (BRD, TDD, etc.) don't always translate across sectors, companies, or even divisions within companies. For example, I've been working in software development for 14 years and I've never heard the term "conceptual requirements." It's in fact somewhat likely that there's a formal template somewhere in your company's document control system for each document type, which might offer some instructions and explanation of the purpose of each, the expected inputs and outputs, etc.

As sort of a middle ground, you might try to explore the regulations or standards that govern your sector of the industry. I work in healthcare IT, not telecom, but for purposes of example, all of our corporate software development processes are designed to meet the requirements of:

* 21 CFR Part 820 (the FDA's Quality System Regulation for design and development of medical devices)
* ISO 9001 (an international standard for general quality system management)
* ISO 13485 (medical device quality management)
* probably others that I'm forgetting

Even if you're not operating in a sector that's directly regulated by government bodies, your company might voluntarily submit to external audits against ISO, SAS 70, NIST, etc. While the standards never prescribe a required name for a given document, at least that I've seen, they will invariably require evidence that some business process was completed (risk assessment, analysis of user requirements, etc.) That's sometimes the main reason that the company-specific process documents exist, frankly.
posted by slenderloris at 1:33 PM on May 5, 2020 [4 favorites]


Best answer: The terms you list are often encountered in software development or IT projects.

First, in your context, have people been using the terms "Waterfall" or "Agile"? "Scrum" will be mentioned in the context of Agile. Atlassian has a pretty good description of scrum, and you can poke around on their site for more info on Agile project management.

TDD, if being mentioned along with Agile and scrum, probably refers to Test Driven Development.

For some of your other bullet points, as mentioned by another poster, it's going to depend on your company. The content and purpose of BRDs and BRSs will depend on the particular project development methodology in use at your company, and may even differ across projects within the same company.

You might want to take a look at this Udemy course, Business Analysis Fundamentals. I have recommended it to folks who had similar questions to yours.
posted by needled at 5:01 PM on May 5, 2020 [1 favorite]


A lot of your TLAs (THREE LETTER ACRONYMS, hurr hurr) might be organization specific, or even business unit specific! Some of these are common although maybe out-of-date, and a lot of them aren’t familiar. Either way, I highly encourage you to play the New Guy card and ask. You will probably find out that you’re not alone.
posted by chesty_a_arthur at 5:33 PM on May 5, 2020 [1 favorite]


Best answer: Nthing the suggestion you ask -- there's no stupid questions, only questions you look stupid for asking a second time.

* A business requirements doc (BRD) might contain a bunch of things that are must have/could have/would like to have (MosCoW), where a business requirement specification (BRS) will be the agreement that says which of those are essential to getting a positive go/no-go outcome when your work is ready to go live.

* 'Scrum leader' might be a 'scrum master' -- which tells us that your organisation is using the Scrum method -- and that role is a servant leader in a delivery team whose responsibility is to get impediments out of the way of the team. Scrum is about arranging people so that the whole team is responsible for getting the product across the line, and it has five repeating events it calls ceremonies that are facilitated by the scrum master[1].

*Test-Driven Development is about exploring the problem space you're trying to solve and recording both working program code and the tests to show it works and doesn't fail. Testing is everyone's responsibility in most agile software development approaches, and good TDD tends to write much less program code and much more relevant test-case code. Principally TDD operates a cycle of (i) write failing tests; (ii) write code to make tests pass; (ii) rearrange the code in your work while keeping your tests passing. (There's two schools, London and Chicago, about how you do that where London emphasises the exploration; and Chicago, the thoroughness in test cases measuring that your code both works positively and doesn't fail.) Updating TDD codebases lets you know if there are unintended consequences of your changes without embarrassing you in front of the rest of your team or your customers, because you can run the tests on your own machine before incorporating them into your version-control source code store --you are using version-controlled storage to manage and revert changes in your code, right?

TDD needs its sibling Behaviour-Driven Development (BDD), which explains workflows in your software in a business-friendly language. BDD usually aligns its test cases with roles of specific users, introduced in the format "as a [user type] I want [capability] so that [objective and key results] occur." Individual tests are written for 'features' in business language with a glue layer that maps them to activate the program and show that it works as promised. For a given workflow that you're testing, each step has a business-language description that lets your business teams understand what's going on, and each test is framed as "given [setup state], when [a test event happens], then [measurable outcomes are recorded to confirm or disprove that it's working OK]."

Both of these approaches to instrumenting your program to record its intent. Paired with a working program, you've got scaffolding to show what the programmers of the time thought they were doing and why the code can do what it does and why it's how it is. Plus the BDD lets you show that you expect the people using your software to do tasks are going to have the experience you've promised them.

So I've written a lot. Look at Manifesto for Agile Software Development for 4 priorities and 12 principles that helped guide teams to deliver work on cadence that's valuable to end users and customers. Then look at scaling beyond the 8-12 people they reckon can work closely on a given sprint's worth of tasks: Lean Enterprise-scale Scrum (LeSS), Scaled Agile for Enterprise (SAFe), Scaling Without a Religious Methodology (SWARM) -- my new favourite search engine lmgtfy.com will point you in the right direction.

1: The team commit to delivering a reasonable amount of work in a two-week sprint and have daily stand-up meetings to say in 15 minutes what each person did yesterday, will do today and is blocked from progressing, then they take adequately-sized small tasks from the queue or backlog and work on them until they meet accepted/acceptance criteria or a definition of done. There's a meeting to break down work into well-understood small chunks known as backlog grooming, a meeting to demonstrate work completed in that sprint and a retrospective on the sprint to reflect upon what the team did and how it can be better.
posted by k3ninho at 4:22 AM on May 6, 2020 [1 favorite]


Best answer: I'm familiar with a lot of these terms and learned them on the job as business analyst for (sounds like you might be one of those!). Looking back, I got in the swing of the acronyms within a few months. You will too!

Taking a weekend workshop by the iiba might accelerate you a little
posted by jander03 at 8:04 PM on May 6, 2020 [1 favorite]


Response by poster: "Business analysis" and "business analyst" were the magic terms I needed to get on the right path. It turns out my company does have official project management framework as well. Between finding that and "business analyst" I'm already in much better shape than I was when I posted this question (though I feel I'm drowning a bit in buzzwords!).
posted by Anonymous at 12:12 PM on May 7, 2020


« Older First time home buyer (remote & out of state)   |   Can't delete some items from Firefox One-click... Newer »
This thread is closed to new comments.