Speech Synthesis – Listen using AWS Polly
The British accent is well suited for synthesis. Their speech in general is more articulated, slower and so more natural pauses. Run on sentences still pose a problem, because a normal speaker will pause to breathe, but not a synthesizer. Also, I’ve noticed the more attention I pay to grammar the better the results, most likely because syntax analysis during synthesizing uses grammar for clues about speech. There is also a markup language SSML that allows you to decorate the text with emphasis, pauses and cadence. I think that’s my next project.
Software teams are obsessed with requirements. If you’ve been in this business long enough, I’m sure you’ve heard variations of “What are the requirements?”, “Where are the requirements?”, “How are we tracking requirements?”, “Are the requirements changing”, “Wait, that’s a requirement ? No one told me!”
Requirements, requirements, requirements – we just can’t get enough of them. We never stop asking about them and we are never satisfied with the level of detail. We won’t be happy until they are so fine-grained we need a microscope to view them. And I’m usually the worst offender when it comes to the requirements brawl. I frequently catch myself thinking, “Could we all just shut up about requirements and start building the software!”
Unfortunately for all of us, the answer is no. Requirements are here to stay, not just at the beginning of the project, but in the middle and the end, and even after the end, if that’s possible. They are fundamental to building and maintaining successful software. The word “requirement” has a special meaning in software development. It’s not a technical term, just a phrase that sort of stuck. It wraps up the various features, goals, objectives, issues, challenges and constraints. They all become requirements. Developing a specific feature is “required” to meet the project’s objectives, committing your source code is “required” to keep track of everyone’s changes. Data is “required” to be encrypted in transit and at rest. We are “required” to handle 50 concurrent requests at a time. We are “required” to complete the project in 12 weeks.
Well, what is a requirement? It’s just information: facts, constraints, objectives, goals and usually some kind of general wish list. They range from the specific, “the image must be 150 pixels wide and high” to the conceptual, “The software needs to be easy to use.” This is a good thing, we need all that information detailed, abstract, conceptual. If it’s part of the project, we need to know and capture it. Every requirement does not need to be exact at first, but they can’t stay that way for long. The information must travel from the general to the specific and on to the exact in short order. Many software projects can be at risk in this phase. The risk comes from moving too quickly from incomplete or vaguely defined requirements to the design phase, where you actually start thinking about how all the technology will work together. If there are missing or vague requirements, they are going to get left out. Software developers cannot design or program anything that is not exact. If the team doesn’t fill in the blanks, we will, sometimes arbitrarily and usually with poor outcomes. Computers only understand the exact. Behind the incredible sophistication of modern software, a computer is no different than the calculator on your desk. And calculators only answer exact questions.
There are as many ways to capture requirements. I’ve seen them captured in Excel, Word, or Google Sheets. There are formal requirements tools. And they all have their strength’s and weaknesses. In general, the tool is not as important as the process. As long as you can capture, track, and assign requirements, you’re good. The how and who of capturing requirements can pretty much be all over the place in different businesses. Sometimes, it’s the project manager (not fair, since they should be managing the requirements process, not doing it), a business analyst (traditional), or the developers (disastrous). There is no one way to capture requirements, but one thing is for sure, it should never be just one person or one department. Requirements capture needs the perspective of everyone who has a stake in the project’s success. They need the insight of different minds who have different jobs and responsibilities to capture the whole thing.
A large group of people contributing requirements is great – the more information we have the better we can design for current and future needs. But it is important to communicate to everyone involved that not every requirement will be developed. There are limitations on budget and time. In the past I’ve written about the importance of ideas and inclusion during the discovery process. At times during requirements, this inclusion can get tricky. There are lots of agendas in an organization, and requirements gathering can be a place for them to compete.
Requirements and agendas aren’t always compatible. Sometimes requirements gathering can reveal jealousies, resentments and competition for resources. I’ve heard comments like, “Why are we building this new software, when the software I manage needs additional work?”, “I proposed this idea last year and it was ignored.” Or other team members trying to lighten their load by folding in their boring daily routines into the project. Hard to blame them but that’s a battle they need to fight, not you. And the usual naysayers and disrupters who just like to disagree about everything. Or, my own flaw, the team members who overcomplicate everything with scenarios that may occur once in an epoch.
So, how to handle some of the disrupters and naysayers. Well, don’t handle them, just write it all down. Not the fact that their naysayers (everyone knows that already), but what they say and contribute. Writing down ideas in requirements gathering is not a contract to develop it. It’s a story of what everyone involved wants the software to do. And, sometimes people like me who overcomplicate things may (rarely) have a valid concern. What seemed like an edge case at first, may occur more frequently than expected. The devil’s advocates can help temper a team’s sunny assumptions. Or maybe that repetitive task someone wants to spend the project’s money on is actually worth the investment. Again, take it all in, it’s just information, try to separate out the personalities from the data. It isn’t easy but it’s always worthwhile.
We focus so closely on requirements because we need to see what everyone wants in their own words. Not re-explained, or edited, but raw. Raw information is very valuable. A lot of larger teams will use business analysts for requirements gathering. That can work very well. Business analysts are at their best when they combine their subject matter expertise with the approach of an investigator or journalist. They keep their distance from the topic, help guide the discussion, keep people from repeating themselves, and focus on listening. Listening is the most valuable skill in any profession, and especially valuable in the requirements gathering process.
Software developers should be part of the requirements gathering process, but for the most part, in my opinion, not in the lead roles. We spend most of our professional time thinking about the “how” not the “why”. In requirements meetings, we will say things like, “Yeah, I can do that” or “Sure, that’s easy” and “That’s not a problem”. We’re thinking about how we can technically complete what is being discussed. Also, we are likely to help the team members fill in the blanks during discussion by leading them toward a solution we’ve already envisioned.
A good interviewer never makes assumptions. A technique I’ve used when talking about software requirements is repetition. First, I listen to the request then repeat it. I restate the request using different language. If we still agree, I write the requirement down in a detailed and structured way. At the next requirements gathering discussion, I circle back and I distribute what I’ve written down. I am always amazed at how even a simple requirement can change during that process. It isn’t because I’m not listening or the stakeholder is not communicating, but because it takes time to reflect and organize information. When you let your brain bake all the ingredients of requirements for a few days, usually, something changes.
As you close in on the end of this initial requirements gathering phase, you’ll start to get a picture of what everyone wants. Now comes the hard part, what’s in and what’s out. This step has nothing to do with any of the structured software development processes and is usually ignored by most systems of how to build software. I know why, because it can become a sticky, political mess, especially in larger organizations. You’ll need to be both honest, diplomatic and able to compromise. It also needs time. Don’t schedule development to start the day after requirements gathering. Rather, schedule the hidden phase of software development – requirements negotiation.
Copyright Honner Consulting LLC 2020