Requirements engineering... with ChatGPT
Introduction
As an engineer and technologist, I've been?exploring the capabilities of developing artificial intelligence?services. So far we have used ChatGPT to generate a Q&A magazine feature, technical role spec, applicant cover letter and CV. We also used AI to plan questions, prompts and responses to a corresponding job interview. Series products to date have been amazing. But it's time to turn it up a notch.
In this (more stretching and substantive) article we hone in on the work of requirements engineering. Our thread continues with an assignment to work on a concept autonomous grocery delivery service. AI outputs include outline planning, stakeholder listing, requirements elicitation prompts, sample service workflow, derived high-level requirements and sub-requirements in turn. AI performs all this based on just a few short prompts from me (see below).
Please take the time to read and process prompts and products below... then hit the comments with reflections as to how roles and crafts might adapt and change in light of AI.
Assignment to works
David: Welcome to GSES Sarah, it's great to have you on board as our Lead Systems Engineer.
Sarah: Thank you, David. I'm thrilled to be here and ready to contribute my expertise to the team.
David: I have your first assignment for you. We're developing a concept for an automated grocery home delivery service in the North West of England. Your role will be to lead the systems engineering effort, which includes identifying and engaging stakeholders, and eliciting their requirements.
Sarah: Of course, I understand. I've had extensive experience in stakeholder engagement and requirements elicitation. I'm familiar with ISO 29148 guidelines, which provide a practical framework for engaging stakeholders in a systematic manner.
David: Excellent, I'm glad to hear that. Can you give me an idea of how you would approach this task on this project?
Sarah: Sure. I would start by identifying all the stakeholders involved in the lifecycle of the automated grocery home delivery service. This would include customers, delivery providers, grocery stores, and any other parties who have a stake in the project's success. Then, I would classify the stakeholders into different categories based on their level of influence and interest. This will help me prioritize my engagement efforts.
Next, I would reach out to the stakeholders and schedule meetings to understand their primary interests and requirements. I would use a combination of surveys, interviews, and focus groups to gather information. During these interactions, I would ensure that I actively listen to the stakeholders, respond to their concerns and ensure their feedback is captured and considered in our requirements elicitation process.
David: That sounds like a comprehensive approach. Can you provide an example of how you've used this method in the past to successfully elicit requirements?
Sarah: Absolutely. I recall a project I led where I was tasked with developing a new transportation management system. I applied a similar approach as I just described and was able to effectively engage with all the stakeholders, including customers, drivers, dispatchers, and government agencies. Through this engagement, I was able to gather their requirements and incorporate them into the system design, which ultimately led to a successful project outcome.
David: Great, it's reassuring to know that you have a proven track record in this area. I have full confidence in your ability to lead this effort. Let's work together to make this project a success.
Sarah: I agree, and I'm looking forward to working with the team and delivering a successful outcome.
Stakeholder Identification
Candidate stakeholders for the autonomous grocery delivery service:
Elicitation prompts
In order to elicit requirements from the stakeholders, the following lines of enquiry can be used:
Customers:
Retailers:
Delivery Companies:
Local Authorities:
Insurance Companies:
Technology Providers:
Sample service workflow
High-level Requirements
RQ-001: Order placement
RQ-002: Order processing
RQ-003: Picking and packing
RQ-004: Delivery
RQ-005: Customer receipt
RQ-006: Customer feedback
领英推荐
Decomposed requirements
RQ-001: Order placement
SRQ-001-1: User authentication
SRQ-001-2: Order form
SRQ-001-3: Payment processing
RQ-002: Order processing
SRQ-002-1: Order validation
SRQ-002-2: Delivery time slot selection
SRQ-002-3: Order confirmation
RQ-003: Picking and packing
SRQ-003-1: Inventory management
SRQ-003-2: Picking process
SRQ-003-3: Packing process
RQ-004: Delivery
SRQ-004-1: Delivery vehicle
SRQ-004-2: Delivery route planning
SRQ-004-3: Delivery tracking
RQ-005: Customer receipt
SRQ-005-1: Delivery notification
SRQ-005-2: Receipt generation
RQ-006: Customer feedback
SRQ-006-1: Feedback form
SRQ-006-2: Feedback analysis
My scripted prompts
I would like you to generate a short dialogue between David (GSES Director) and Sarah Johnson (a newly appointed Lead Systems Engineer). David should welcome the new recruit and introduce her first work assignment. The project will be concerned with developing a concept automated grocery home delivery service in the North West of England. David expects Sarah to know how to identify, classify and engage lifecycle stakeholders, identify their primary interests and elicit outline requirements. Sarah should be able to articulate how she will do this consistent with her brief, expertise and ISO 29148. The dialogue should be personable, professional and assure David of Sarah's capability to deliver the assignment. David may seek elaboration on any given point. Sarah may need to follow up with qualifying examples, terms and / or potential deliverables.
I want you to assume the role of a requirements engineer working on a concept autonomous grocery delivery service. The envisaged solution will not employ human delivery drivers. Automated technology will instead pick, pack and transport goods. Please list candidate stakeholders, prospective corresponding interests, and at least 3 lines of enquiry for elicitation of requirements.
Suggest a workflow for ordering through to fulfilment.
Translate these steps to high-level requirements and format in a consolidated list with unique identifiers and accompanying rationale. Requirements format shall follow INCOSE requirements writing guidelines.
I would like you to derive sub-requirements for each high-level requirement, ensuring consistency with original requirements. Please present in a hierarchical list with an ID, description and rationale for each sub requirement.
Rob Black very interesting article, I can see this as a potentially fruitful use of LLMs. Would you be willing to provide more information on the context you used for this experiment? For instance, did you do this in the openai.com/playground or some other tool you have created? It would be great to know the tuning parameters you used: model, mode, temperature, etc.
Senior Expert Digitised Railway Operation at DB Netz AG
2 年Nonsense. The most it can do is string together a readable sentence in natural language. It has no ability to question stakeholders, interpret their input based on engineering knowledge, nor to make optimisation decisions. Read ISO 29148 and you'll begin to understand that there is more to requirements engineering than a handful of "shall" statements.
PhD || 22 Years into Engineering, Products & SW - Train Control, SIG, ISRO || Patents || NIT, Trichy
2 年Shantanu Deshmukh
Systems Thinker | Improvements Lead - BSc (Hons), CMgr FCMI, FICIPS, CSEP MINCOSE, CPRE IREB, AMBCS, APM-PMQ
2 年A follow-up on using defined rulesets - https://www.dhirubhai.net/pulse/easy-approach-requirements-syntax-ears-chatgpt-rob-black
Systems Engineering | Enterprise Architecture | I&ST
2 年Thanks for sharing. I shall replace "can do" with "can help do". Indeed, it could help, for instance, by providing designers with reusable and synthetic prior (consumable by AI) data -- e.g. when a newly engineered system can be compared with former engineered systems. In this case, some means of (feasibility) verification -- of the provided data -- would be more than necessary. The point is: beware of confusing accuracy with appropriateness. I like the quote: "... But accurate accounting does not distinguish between a good financial plan and a bad one, nor help to make a bad one better. Similarly, accurate control of interfaces and requirements is necessary to good systems engineering, but no amount of care in such matters can make a poor design concept better. Systems engineering is first and foremost about getting the right design -- and then about maintaining and enhancing its technical integrity, as well as managing complexity with good processes to get the design right. ..." To sum up, AI can help do systems enginering (and many other things), but cannot do it.