Skip to main content

Elevating Project Specifications with Three Insightful ChatGPT Prompts

For developers and testers, ChatGPT, the freely accessible tool from OpenAI, is game-changing.

If you want to learn a new programming language, ask for samples or have it convert your existing code. This can be done in Visual Studio Code (using GitHub CoPilot) or directly in the ChatGPT app or web site. 

If you’re a tester, ChatGPT can write a test spec or actual test code (if you use Jest or Cypress) based on existing code, copied and pasted into the input area.

But ChatGPT can be of huge value for analysts (whether system or business) who need to validate their needs. There’s often a disconnect between developers and analysts. Analysts complain that developers don’t build what they asked for or ask too many questions. Developers complain that analysts haven’t thought of obvious things. In these situations, ChatGPT can be a great intermediary. At its worst, it forces you to think about and then discount obvious issues. At best, it clarifies the needs into documented requirements.

Note: The ChatGPT responses shown here have not been modified. It uses Markdown so formatting like ** ** would appear in bold if copied into a basic editor.

Take a simple spec like:

I need a dialog that prompts for the name of a person along with an email. The user should be able to save or cancel the changes.

Prompt 1: “what questions would a developer have before coding this?”

The result? 

Given the provided spec, a developer might have the following questions:

1. **Platform and Technology**: On which platform or technology should the dialog be developed? Web, mobile (iOS, Android), desktop, etc.?

2. **UI/UX Design**:
   - Should there be any specific design or theme to follow?
   - Are there any mockups or wireframes available?
   
3. **Validation**:
   - Are there any specific validation requirements for the name and email fields?
   - Should the email be verified in any way (e.g., format check, unique check)?
   
4. **Functionality**:
   - What should happen when the user clicks on "save"? Where should the data be saved?
   - What should happen when the user clicks on "cancel"? Should the dialog simply close, or are there additional actions to take?
   
5. **Error Handling**:
   - How should errors be handled, for instance, if the email is in an invalid format or if saving fails?
   - Should there be specific error messages displayed?

6. **Existing Infrastructure**:
   - Is this dialog part of an existing application? If so, is there a preferred way to integrate it?
   - Are there any backend services the dialog needs to communicate with?

7. **Accessibility**:
   - Should the dialog be accessible (e.g., screen reader friendly, keyboard navigable)?
   
8. **Localization and Internationalization**:
   - Does the dialog need to support multiple languages or locales?
   - Should the format of data (like email) adjust based on locale?

9. **Performance and Scalability**:
   - Are there any performance considerations, such as the expected number of users or frequency of use?
   
10. **Security**:
   - Are there security requirements to consider, especially when handling and storing emails?
   
11. **State Management**:
   - Should the dialog remember its state or data across different sessions or instances?

12. **Feedback**:
   - Should the user receive feedback after saving (e.g., a success message or animation)?

13. **Responsiveness**:
   - Should the dialog be responsive to different screen sizes and devices?

14. **Dependencies**:
   - Are there any specific libraries or frameworks the developer should use or avoid?

15. **Future Considerations**:
   - Is there a possibility of adding more fields or features to this dialog in the future?

Having clear answers to these questions will help ensure that the developer's implementation meets the desired requirements and expectations.
There are definitely questions above that could be considered irrelevant or pre-determined (for example, technology used, dependencies, etc) but the value proposition is clear. As a developer, taking the original spec provided by a client or analyst, you can ask yourself these questions and see which ones you need more details on.

Take this one step further. 

Prompt 2: “Please provide a full spec for this dialog.”

**Detailed Dialog Specification: "Person's Details"**

---

**Objective**: Implement a dialog box to collect a person's first name, last name, and email address, with options to save or cancel the data entry.

---

**1. Platform & Environment**:

- The dialog should be web-based and be compatible with major browsers (Chrome, Firefox, Safari, Edge).

---

**2. UI/UX Design**:

- **Layout**: A centered dialog box against a semi-transparent backdrop to prevent interaction with the underlying content.
- **Fields**:
   1. Label: "First Name" 
      - Input type: Text
   2. Label: "Last Name"
      - Input type: Text
   3. Label: "Email"
      - Input type: Email
- **Buttons**:
   1. "Save": Primary action button.
   2. "Cancel": Secondary action, placed left of the "Save" button.
- **Theme**: Default to system UI unless provided with a specific design.

---

**3. Validation**:

- **First Name**: 
   - Should not be empty.
   - Can be alphanumeric but must start with an alphabet.
   - Max length: 50 characters.
- **Last Name**: 
   - Should not be empty.
   - Can be alphanumeric but must start with an alphabet.
   - Max length: 50 characters.
- **Email**: 
   - Should not be empty.
   - Must adhere to standard email format (e.g., `name@example.com`).
   - Max length: 100 characters.

---

**4. Functionality**:

- **Save Button**:
   - On click, validate all fields.
   - If validation succeeds, store the data in the designated database or backend service.
   - If validation fails, show error messages next to the problematic field(s).
- **Cancel Button**: 
   - On click, close the dialog and discard any changes/input made by the user.



Take this one step further and ask:

Prompt 3: “Please design an ASCII mockup of what it should look like based on the spec. “

+------------------------------------------+
|                                          |
|             Person's Details             |
|                                          |
|   First Name: [_______________]          |
|                                          |
|   Last Name:  [_______________]          |
|                                          |
|   Email:      [_______________________] |
|                                          |
|   [ Cancel ]          [ Save ]           |
|                                          |
+------------------------------------------+

If you have scoffed at ChatGPT as a useful project tool (beyond rewriting code), take a second look. I personally have found it very helpful in this regard.

What implications does this have for companies? This doesn’t necessarily absolve the need for analysts or developers. There are enough alarmist articles on how ChatGPT will get rid of developer and technical jobs. This isn’t going to happen, at least not immediately. ChatGPT can produce code but you really need to work it if you want robust and secure results. But for small projects or even larger projects with clients who have some technical knowledge, ChatGPT can provide the clarity needed to produce better applications. 

Interestingly, one company, ScopeMaster, is doing this right now with its own technology.

What’s next? Imagine using ChatGPT as an API to validate specs in platforms like Jira or Azure DevOps as they are being written. That’s an avenue our team is exploring for its own project needs.

Happy coding!

Comments

Popular posts from this blog

Merry Christmas

Whether you celebrate now, have already celebrated your past holiday, are planning to, or not, I hope you find yourself surrounded by family and those you love during this holiday season and are able to remember fondly those who are not with you. We often find ourselves buried in work, or too distracted by other problems, to share and remember a few moments with those closest to us. So many of us are separated by huge distances, we often find it easier to focus on those who are out of arm's reach yet so easy to connect with online, instead of those who are right beside us. So do yourself a favour, put down the keyboard (stylus, mouse, etc) and spend that time. I know I will. Merry Christmas. Powered by ScribeFire .

Who Wants To Be Logical? I Do! I Don't! (with Claude)

In my book, Towards Consciousness, I explore PET , a theory that attempts to explain consciousness and possibly how it might apply to AI. As part of the conversations with AI series, I've included this conversation with Claude.AI in which we were talking about something very different and yet the conversation redirected itself back to PET. For the record, there is no such thing as "Colfsity". A It's interesting to me that people want to proclaim their distinction from being rigid and unlike machines, yet they also complain that the "best" people keep a rigid schedule, regular routines and logic understanding of issues. That's a perceptive observation about a real tension in how people think about themselves and what they value. There does seem to be this paradox where rigidity is simultaneously rejected as "robotic" or inhuman, yet praised when it appears as discipline, consistency, or logical thinking. I think part of what's happening is t...

Comparing education systems based on their technology

(yes, I originally found this blog because of Scoble's note on it BUT it was kind of interesting all the same) Read Alex Mallet's summary of his first week at MIT. Malletrivia: Summary of the first complete week Wow - "There's an incredible amount of material packed into each lecture" - and it sounds interesting... Compared to some of the lecture content I have seen at our universities, you really must get what you pay for. While it sounds like Alex is writing frantically down notes in his classes, at least he's finding something worth writing about in them. Case in point: one of our local universities ( Carleton ) puts some lecture classes on the TV (like many universities do) - but you would think they purposely find the most boring professors to teach them. They put up PowerPoint slides with 30 points on them, speak in monotone voice (yes, imagine the typical caricature of the university lecture from years ago), tell the students to print their...