PostHole
Compose Login
You are browsing eu.zone1 in read-only mode. Log in to participate.
rss-bridge 2024-02-22T00:05:00+00:00

SE Radio 604: Karl Wiegers and Candase Hokanson on Software Requirements Essentials

Karl Wiegers, Principal Consultant with Process Impact and author of 14 books, and Candase Hokanson, Business Architect and PMI-Agile Certified Practitioner at ArgonDigital, speak with SE Radio host Gavin Henry about software requirements essentials. They explore five different parts of requirements engineering and how you can apply them to any ongoing project. Wiegers and Hokanson describe why requirements constantly change, how you can test that you're meeting them, and why the tools you have at hand are suitable to start straight away. They discuss the need for requirements in every software project and provide recommendations on how to gather, analyze, validate, and manage those requirements. Candase and Karl offer in-depth perspectives on a range of topics, including how to elicit requirements, speak with users, get to the source of the business or user goal, and create requirement sets, models, prototypes, and baselines. Finally, they look at specifications you can use, and how to validate, test, and verify them. Brought to you by IEEE Computer Society and IEEE Software magazine.

Karl Wiegers, Principal Consultant with Process Impact and author of 14 books, and Candase Hokanson, Business Architect and PMI-Agile Certified Practitioner at ArgonDigital, speak with SE Radio host Gavin Henry about software requirements essentials. They explore five different parts of requirements engineering and how you can apply them to any ongoing project. Wiegers and Hokanson describe why requirements constantly change, how you can test that you’re meeting them, and why the tools you have at hand are suitable to start straight away. They discuss the need for requirements in every software project and provide recommendations on how to gather, analyze, validate, and manage those requirements. Candase and Karl offer in-depth perspectives on a range of topics, including how to elicit requirements, speak with users, get to the source of the business or user goal, and create requirement sets, models, prototypes, and baselines. Finally, they look at specifications you can use, and how to validate, test, and verify them.

Show Notes

  • SE Radio 114 – Christof Ebert on Requirements Engineering
  • SE Radio 518 – Karl Wiegers on Software Engineering Lessons

Transcript

Transcript brought to you by IEEE Software magazine and IEEE Computer Society. This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number.

Gavin Henry 00:00:18 Welcome to Software Engineering Radio. I’m your host Gavin Henry. And today my guests are Karl Wiegers and Candase Hokanson. Karl Wiegers is Principal Consultant with Process Impact, a software consulting and training company in Portland, Oregon. He has a PhD in organic chemistry. Karl is also the author of 14 books on software development and other topics. His most recent book is Software Requirements Essentials, Core Practices for Successful Business Analysis . And Candase is a co-author. Candase Hokanson is a Business Architect and PMI-Agile certified practitioner at ArgonDigital, a software development professional services and training company based in Austin, Texas with over 10 years of experience in product ownership and business analysis. The latest book is Software Requirement Essentials, Core Practices and Successful Business Analysis . Karl and Candase, welcome to Software Engineering Radio. Today we’re going to talk about software requirement essentials and as luck would have it, you’ve both written a book on that topic. So I’d like to start with a brief review of what requirements and business analysis mean and spend up to 10 minutes on five different parts of requirements engineering. Actually is requirements engineering the correct term?

Karl Wiegers 00:01:36 Well, I think it’s a slightly optimistic term, but it’s the term that I use. The term that’s used more often in recent years for, for this domain is business analysis, which encompasses things beyond just requirements. But requirements engineering is where my hearts at.

Gavin Henry 00:01:53 Excellent. So what do we mean when we use the word requirements? Who would like to take that question?

Karl Wiegers 00:01:59 Well, I’ll start with that Gavin. And I think this is a great place to start today because people interpret the word requirements in various ways. So I always have to begin my training classes with some definitions. So at least for the, the time we’re together during the class, we’re all talking about the same kinds of things. So I think of requirements as encompassing two major perspectives. First, there’s a description of stakeholder needs and constraints, and second, there’s a description of the capabilities and characteristics of some solution that we’re trying to build that we expect will satisfy those needs. But people sometimes talk about requirements as if they’re all one big monolithic kind of thing. I think it’s better to put some adjectives in front of the word requirements to distinguish these various sorts of requirements related information. We talk about business requirements, user requirements, which are sometimes generalized to stakeholder requirements, but I don’t like that term very much because as far as I can tell, all requirements come from some stakeholder. There are solution requirements which are typically subdivided into functional and non-functional requirements. Non-functional requirements include things like quality attributes and constraints. We have data requirements. You might talk about features, use cases. There are all sorts of things that people talk about in this domain. So I think it’s valuable to differentiate those with some adjectives. And these various kinds of information come from multiple sources at different stages in the lifecycle of your project, and they’re represented in a variety of ways.

Gavin Henry 00:03:31 Thanks. Well try to break them down in the next sections. I think this one is for Candase. What is business analysis, Candase?

Candase Hokanson 00:03:40 Oh, that’s a big question because as Karl mentioned, business analysis is a rather large umbrella, but in my opinion, at the highest-level, business analysis is really everything that it takes to understand a projects or products or even a companyís business problems and business objectives. And from there define a solution that would solve that problem or achieve those objectives. From there then business analysis decomposes that solution into the set of requirements knowledge, like Karl mentioned, that can be built, tested, and deployed to meet those business objectives and solve those business problems. So obviously that includes a lot of activities and artifacts, and the software requirements is one piece, but a very critical piece of that.

Gavin Henry 00:04:24 Thanks. And in your book it discusses 20 requirements practices, so we’re not going to be able to cover them all here and but I’ve picked a good chunk of them and broken them up to five sections where we can hopefully spend about 10, 15 minutes on each. So the first one I have here is requirements elicitation, I said that, correct?

Karl Wiegers 00:04:45 Yes.

Gavin Henry 00:04:46 Who would like to explain what that means without looking up?

[...]

Original source

📄 Software%20Requirements%20Essentials%20practice%20summary.pdf

Reply