human: Given a node-centered hypergraph: <hypergraph>, where nodes represent papers and hyperedges represent sets of papers co-cited by a source paper.

Details of the hypergraph:
Center node: "expressing and verifying embedded software requirements"
  Abstract: Writing requirements for embedded software is pointless unless they reflect actual needs and the final software implements them. In usual approaches, the use of different notations for requirements (often natural language) and code (a programming language) makes both conditions elusive. To address the problem, we propose to write requirements in the programming language itself. The expected advantages of this seamless approach, called AutoReq include: avoiding the potentially costly miss due to the use of different notations; facilitating software change and evolution, by making it easier to update code when requirements change and conversely; benefiting from the remarkable expressive power of modern object-oriented programming languages, while retaining a level of abstraction appropriate for requirements; leveraging, in both requirements and code, the ideas of Design by Contract, including (as the article shows) applying Hoare-style assertions to express temporal-logic-style properties and timing constraints; and taking advantage of the powerful verification tools that have been developed in recent years. The last goal, verification, is a focus of this article. While the idea of verifying requirements is not widely applied, the use of a precise formalism and a modern program prover (in our case, AutoProof for Eiffel) makes it possible at a very early stage to identify errors and inconsistencies which would, if not caught in the requirements, contaminate the final code. Applying the approach to a well-documented industrial example (a landing gear system) allowed a mechanical proof of consistency and uncovered an error in a previously published discussion of the problem.

Connected through hyperedge HE-1 (induced by source paper "object oriented requirements reusable understandable verifiable"):
  with members:
    - "complete contracts through specification drivers"
    - "unifying requirements and code an example"
    - "autoproof auto active functional verification of object oriented programs"

Question: Please tell me which class the center node belongs to. The 40 classes are: cs.NA(Numerical Analysis), cs.MM(Multimedia), cs.LO(Logic in Computer Science), cs.CY(Computers and Society), cs.CR(Cryptography and Security), cs.DC(Distributed, Parallel, and Cluster Computing), cs.HC(Human-Computer Interaction), cs.CE(Computational Engineering, Finance, and Science), cs.NI(Networking and Internet Architecture), cs.CC(Computational Complexity), cs.AI(Artificial Intelligence), cs.MA(Multiagent Systems), cs.GL(General Literature), cs.NE(Neural and Evolutionary Computing), cs.SC(Symbolic Computation), cs.AR(Hardware Architecture), cs.CV(Computer Vision and Pattern Recognition), cs.GR(Graphics), cs.ET(Emerging Technologies), cs.SY(Systems and Control), cs.CG(Computational Geometry), cs.OH(Other Computer Science), cs.PL(Programming Languages), cs.SE(Software Engineering), cs.LG(Machine Learning), cs.SD(Sound), cs.SI(Social and Information Networks), cs.RO(Robotics), cs.IT(Information Theory), cs.PF(Performance), cs.CL(Computation and Language), cs.IR(Information Retrieval), cs.MS(Mathematical Software), cs.FL(Formal Languages and Automata Theory), cs.DS(Data Structures and Algorithms), cs.OS(Operating Systems), cs.GT(Computer Science and Game Theory), cs.DB(Databases), cs.DL(Digital Libraries), cs.DM(Discrete Mathematics). Directly output the class name.

gpt: cs.SE(Software Engineering)