Author of "Software Requirements Essentials" and 13 other books. PhD in organic chemistry. Principal Consultant at Process Impact. No certifications at all.
People sometimes talk about “the user” for a product as though all users belong to a monolithic group with similar characteristics and expectations. In reality, most products of any size appeal to a diversity of users with different expectations and goals. Rather than thinking of “the user” or “the stakeholder” in singular, spend some time identifying your product’s multiple user classes and understanding their needs and constraints. This article describes why it’s valuable to group users into distinct user classes and several ways to approach that analysis. #requirements #requirementsengineering #user #users #userexperience #customers #stakeholders #businessanalysis #businessanalyst #agile #softwaredevelopment #softwareengineering https://lnkd.in/gqVsuYGk
John Watson
4mo
An attempt at defining "User" see https://www.linkedin.com/pulse/userstakeholder-john-watson-qm50c
John Watson
4mo
Back in the day...I was working with a multi-national hardware and software supplier. Part of my job was to maintain the COBOL compilers and various operating systems. We spoke of software developers (systems programmers and application programmers) as users. As Karl says there are many classes of user. I do think it important to differentiate between users and customers. Those who buy the product are customers who might or might not also use the product. Customers requirements are not user requirements.
Stéphane BADREAU
4mo
Thanks Karl Wiegers Yes of course, users are stakeholders and just like others, they must be identified and classified based on their profiles, optinions, expectations, etc... Camille Lambert
Senior Consultant, Managing Member at Wheatland Consulting, LLC.; Chair of the INCOSE Requirements Working Group (RWG).
4moGreat advice! There are multiple stakeholders and not just users or customers. Their needs can be conflicting, incomplete, inconsistent, incorrect with feasibility not addressed. There is a lot of work to be done in the beginning to resolve these issues, identify drivers and constraints, assess risk, and define a set of lifecycle concepts that is consistent, complete, correct, and feasible. From these lifecycle concepts, a well-formed set of needs can be defined and baselined that represents the scope of the project and against which the design input requirements, design, and realized system can be validated.