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

Blogs and RSS come to Microsoft.com

MS has just introduced their portal and it's pretty comprehensive. Nothing quite like learning that some people use AIM instead of MSN messenger, or that there really may be a need for supporting 4 monitors ( Cyrus Complains ) However, it's really a great sign that MS is serious about supporting the blogging community which seems to have um, exploded in size in the past year. Blogs and RSS come to Microsoft.com

FoxInCloud Stats

FoxInCloud sent this link a while back about their statistics regarding visits to their site: http://foxincloud.com/blog/2017/12/27/VFP-community-lessons-from-foxincloud-site.html What's interesting here is the breakdown of people. Yes, I think it's understandable that the Fox community is getting older. Another factor is the growth of the mobile and web environments taking over development. These environments really do push people towards the newer non-SQL or free SQL/hosted environments but more towards hosted storage options like Amazon and Google. A tool like FoxInCloud that helps MOVE existing applications to the cloud inherently competes with those environments. But FoxInCloud also allows developers to extend their application further by giving them a starting point using Javascript and the basic CSS (such as Bootstrap). If you're not rebuilding your application from scratch, it's certainly a great step forward. FoxPro VFP

Programmers vs. Developers vs. Architects

I received an email this morning from Brandon Savage 's newsletter. Brandon's a PHP guru (works at Mozilla) but his newsletter and books have some great overall perspectives for developers of all languages. However, this last one (What's the difference between developers and architects?) kind of rubs me the wrong way. Either that, or I've just missed the natural inflation of job descriptions. (maybe, it's like the change in terminology between Garbage man and Waste Engineer or Secretary and Office Administrator) So maybe it's just me - but I think there's still a big difference between Programmer, Developer and then of course, architect. The key thing here is that every role has a different perspective and every one of those perspectives has value. The original MSF create roles like Product Manager, Program Manager, Developer, Tester, etc - so every concept may pigeon hole people into different roles. But the statements Brandon makes are often distinction